stokes:Okay. Great. Hi, everyone this is Acdc, number 1, 62.
Transcript
stokes:It's issue 1638 in the Pm repo.
stokes: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.
stokes: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.
stokes: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.
Parithosh Jayanthi: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.
Parithosh Jayanthi: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
Parithosh Jayanthi:log. How long it takes for the network to be okay again.
Parithosh Jayanthi: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
Parithosh Jayanthi:tests we have.
Parithosh Jayanthi:This is all to do with Devnet 3
Parithosh Jayanthi:before we started earlier today, we had a hundred percent participation, which is great to see.
Parithosh Jayanthi: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.
Parithosh Jayanthi: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
Parithosh Jayanthi:is, we expect it to run on roughly, 10% of maintenance, and this should give us a decent idea on how pure scales.
Parithosh Jayanthi:and we should be able to present it in 2 weeks at Actc again.
Parithosh Jayanthi: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.
stokes:Alright great, awesome.
stokes: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?
stokes:Okay, you're on discord.
stokes:I'll just grab this thing.
Parithosh Jayanthi:Yeah, I sent the message, and we can create a thread and discuss it. There.
stokes:Okay, cool.
stokes:Thank you.
stokes: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.
stokes:And yeah, I think from there, that takes us into the next thing I wanted to talk about which is the Bpo schedule. So
stokes: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.
stokes:And essentially, it's time now to think about what the schedule should be for Posaka
stokes: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?
stokes:Sure.
Justin Traglia:One second
Justin Traglia:alright! Can everyone see that.
stokes:Yep.
Justin Traglia:Cool
Justin Traglia: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.
Justin Traglia:I've made this proposal.
Justin Traglia:which I believe would work well. There's a single phase with 3 Bpo forks. There's approximately one month between each Bpo fork.
Justin Traglia:and after 3 months we had target 21 blobs and with a limit of 32 blobs per block
Justin Traglia: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
Justin Traglia:I propose for the Fusaka upgrade to happen. End of October beginning of November.
Justin Traglia:yep, and then, like, I said before, like a month between. So
Justin Traglia:the 1st Vp. Of work would be December 15th
Justin Traglia:before Christmas, and after Thanksgiving in the Us.
Justin Traglia:Bpo. 2 would be January 14, th 2026, another month later.
Justin Traglia:and then Bpo, 3 would be February 10.th
Justin Traglia:Approximately these times that I've chosen are best for like Asia and Australia.
Justin Traglia:Because there are so many people working on Peer to ask there.
Justin Traglia:Oh, yes.
Justin Traglia:So I just kind of want to get a broad agreement on what we think this should look like, and what our priorities are.
Justin Traglia:Thoughts.
stokes:Cool. Thank you. Yeah. So I guess one other thing here, just to ground the discussion.
stokes: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
stokes: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.
stokes:We'd have another phase early, 2026. That would add more Bpos to get us up to 8 x throughput again, assuming everything looks
stokes:good, and there are no surprises as we start to scale
stokes:from there in terms of this chunk of things.
stokes:Yeah, I think the main thing is just the dates.
stokes:at least for me. These are pretty spaced apart, and we could compress them a bit.
stokes: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
stokes: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
stokes:players in the ecosystem who would like to be roll up so basically aren't
stokes:just because they see there's not enough da throughput for for their use cases so given all that.
stokes:Anyone else have any other comments about this document and this general shape of the Bpos.
stokes:I think one other thing here I think Pandops is planning to do testing to validate these numbers.
stokes: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.
stokes:Okay? So yeah, so basically, we'd have
stokes: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
stokes:then, otherwise the question is more up to us as to like what kind of space we want.
stokes:you know, if this is like much more compressed, and we have less time to observe Mainnet.
stokes:But again, if we just delay it
stokes:because we can. Then it'll just take much longer to get to say an 8 x amount of scaling.
stokes:So with all that, said, anyone else have any other comments.
stokes: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
stokes:a potential 8 x in April of next year.
stokes:Does anyone have any input here?
stokes:They think to subscribe?
stokes:I did have a different salute or a suggestion.
stokes:Let me go find the comments. Yeah, basically moving the dates a bit up.
stokes: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.
stokes:Anyone have any comments either way.
stokes: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.
Ansgar Dietrichs:And do we would we want to already in advance kind of have some sort of ballpark understanding of
Ansgar Dietrichs: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
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Ansgar Dietrichs:and delay and and put more more time into into validation.
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.
ethDreamer (Mark):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
ethDreamer (Mark):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
ethDreamer (Mark):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.
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.
stokes: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.
stokes: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.
stokes:And yeah, wanted to make the point that
stokes: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.
stokes:But ultimately, yeah, wanted to open that thread today.
stokes:And yeah, I'm sure this is something we'll circle back to on future calls.
stokes:So unless there are any other comments or questions on that Bpo schedule.
stokes:let's move to some testing updates. So this is following a thread from acdt on Monday.
stokes:where there was some discussion around, I think at least 2 different things. There's this notion of this like perfect, pure desk configuration.
stokes:and having node being able to sync.
stokes: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.
stokes: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.
stokes:Are there any things? Yeah, any updates here or things we should discuss.
Matthew Keil:Is this the right time to talk about timeline.
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
Matthew Keil: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.
Matthew Keil: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
Matthew Keil:the testing that we think might also be beneficial. To give peace of mind and to move to to main it smoothly.
Matthew Keil:the major concern is that
Matthew Keil: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
Matthew Keil: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.
Matthew Keil: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.
Matthew Keil:And so now, being able to
Matthew Keil:to test, to execute that code or to exercise those code bats on on trunk branches. We think is is critically important.
Matthew Keil:the timeline that we've been talking about is basically 4 extra weeks.
Matthew Keil:So end of September.
Matthew Keil:And this is something that
Matthew Keil: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
Matthew Keil:on trunk branch is is critically important for the success of this rollout.
Matthew Keil:there's also been no private mempool testing up to this point, and there is a concern that the get blocks. V. 2
Matthew Keil:has been a crutch in order to make sure that syncing and and following head works well. And
Matthew Keil: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
Matthew Keil:having a really deep heart to heart about this, because we know the importance and the critical nature of getting these timelines met.
Matthew Keil:so I
Matthew Keil:I want to open the floor, though, in case I've missed anything to to the other people that also feel that
Matthew Keil:that we need a little more discussion.
Matthew Keil: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.
Matthew Keil:If they feel comfortable speaking up, please feel free. I was just on the call with Manu and and Dustin.
Manu:Yes, so yes, my one of my concern was yes, the fact that we should test
Manu:We should test as clients without the help of the 2. I noticed that
Manu:we had a lot of failing devnets pure. Designate 3, 4, 5,
Manu:and I don't remember exactly when pure das B. 2 was introduced, but I do remember that
Manu:as soon as Peerdas v. 2 was introduced, so Devnet started to be really stable.
Manu:That's why, yes, I think we should have
Manu:something really close to Mainnet regarding private Main pool. I'm talking about private, because when you
Manu:have at least one blob, which is in a private name pool. The Getlob v. 2 does not help at all.
Manu:and we should have something very close to to my net about about this private connection. When I look at now on door explorer.
Manu:it seems we don't have a lot of
Manu:blocks with private private blobs. I mean parito.
Manu: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: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.
Barnabas: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
Parithosh Jayanthi:and this was all with private clubs.
Matthew Keil:You know, and I.
Barnabas:In rest right now. Where the transactions don't get passed to the our builder. That bug is actually being worked on right now.
Barnabas: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
Matthew Keil: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
Matthew Keil: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.
Matthew Keil: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
Matthew Keil: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
Matthew Keil: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
Matthew Keil: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.
Matthew Keil: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.
Matthew Keil:and it was a simple constant that caused it to go haywire. And then.
Matthew Keil: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
Matthew Keil: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: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.
Dustin:one of the challenges with achieving. That was that especially because it were definite one and definite. 2 things were changing quickly enough that
Dustin:it was sort of a
Dustin: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.
Dustin:and and by the time that, like the very moment again, metaphorically, that the dead net 3 is becoming kind of stable.
Dustin: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.
Dustin:And and Petra did not have this timing issue where it was immediate turnaround from
Dustin: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.
Matthew Keil:And this is exactly why we wanted to at least bring up the
Matthew Keil:bring it up. And I think that's probably the you know we we talked about some of this timing.
Matthew Keil: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.
Matthew Keil:and that would leave dev connect
Matthew Keil: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.
Matthew Keil:But
Matthew Keil: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
Matthew Keil:you know I don't any thoughts about that.
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.
Matthew Keil:That would push Mainnet from where it stands today. To it would be just after
Matthew Keil:devconnect, or possibly at Devconnect.
Matthew Keil: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.
Matthew Keil:you know. I don't know if that's creates more.
stokes:If everyone's gonna be at Dove connect, it's kind of far for some people.
stokes: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.
stokes: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
Matthew Keil: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
Matthew Keil: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
Matthew Keil:after releases are done. You know, in the month of September.
Matthew Keil:and so that 4 weeks really buys the time in order to do that, to do the additional testing on on trunk branches.
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.
Matthew Keil:but I I would like to, you know.
Matthew Keil: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:No, I think that. Oh, sorry. Go go ahead.
Manu:Oh, okay, thank you. Yeah, for prism. I think it's
Manu:do. I want to merge everything for
Manu:September first, st but it will, you know at very later time. You need to be absolutely confident about the code we match.
Manu:So definitely, I think for more weeks we'll
Manu:helps a lot. And additional thing is, if we sorry. If we
Manu:run as a new devnet so devnet. For before
Manu:the code is merging in trunks, that means that we will have some
Manu:code in our code base which goes through
Manu:Fuzaka and Bpo. One Bpo. 2 and Bpo. M. Which are never on the trunk branch.
Manu:So I think the last devnet
Manu:should definitely be run on the trunk branch of every client. To be sure that you know the
Manu:the 4th epoch is running on the trunk branch.
Manu:Yeah.
Manu:And exception is maybe holistic, actually.
Manu:for sure, for Sepoli and Hoodie should be the case.
stokes:Yeah, I mean, yeah. So there is the suggestion here to do Haulaski. So on September.
stokes:what exactly does this buy us
stokes:other than we can just see it live, I guess.
Matthew Keil:Yeah, and making sure that all the interrupts work correctly
Matthew Keil:like that to us, we feel is is important.
stokes:Right? And so, okay. But then I guess the concern then is that we wouldn't have everything on a trunk
stokes:release. Let's call it.
Manu:Just a random question, is it possible to run a devnet after holly?
Manu:Or yeah, I think sure.
stokes:Yeah, we can run demos whenever, yeah.
Manu:Yeah.
Parithosh Jayanthi:Also, we're planning on continuing testing until being that we wouldn't be stopping. Once we have releases.
Manu:Oh, okay.
Barnabas: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.
Barnabas:still planning to do maintenance in November.
Barnabas:So like we can, we can get Host Key, release it out on a feature branch.
Barnabas:Someone is not ready, and if someone is ready, then we're gonna use their front branch
Barnabas:like I. I don't see this as a absolute blocker. We can have a client releases for sepulia.
Barnabas:If we need to, we can push that by 2 weeks and then,
Barnabas: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
Matthew Keil:that's the big concern, you know, considering that we're going to do non finality testing
Matthew Keil:and backfill really isn't a thing yet for anybody.
Matthew Keil:you know, and that's really where where it starts to become critical is when you get into these non finality situations where
Matthew Keil:you know, you need to make sure that data is propagated pretty widely
Matthew Keil: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
Matthew Keil:arguable.
Matthew Keil:You know, we could probably do that on a devnet 3 style branch, but
Matthew Keil:you know, because we will still see the code exercised
Matthew Keil: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.
stokes:Okay? I mean, can we at least then agree to target helushi in September, are we okay with that
stokes:cause? Yeah, I think where this is heading is
stokes: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.
stokes:Like.
stokes: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.
stokes:I would say, to move forward.
stokes: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.
stokes: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.
stokes:In the code trunk. So I would focus on that.
stokes: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.
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.
Matthew Keil:And I know everybody, all the people that. I'm speaking on behalf of do as well. So thank you.
stokes:Sure.
stokes:Okay. So
stokes: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.
stokes:with
stokes:perfect peer to us. And this question of backfill. So are there any things we want to discuss now.
stokes:or are we okay.
stokes:I think it was mainly just a question of implementation, so
stokes:there might not be much to to touch on right now.
stokes:Okay, then. Next up there was a Pr here or the beacon Api.
stokes:So let me just get a link.
stokes:And right this is about essentially how the beacon node exposes Bob's to consumers
stokes:is inflag on the call use on there is the point.
nflaig: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
nflaig:instead of indices.
nflaig: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
nflaig:to just return the blob and not the commitments and version test and stuff.
nflaig:So it would be good to get more feedback, especially from layer twos, which will be the consumer of this.
nflaig:yeah, just take a look at the Pr, I think this can be done, Async, unless someone has
nflaig:an opinion.
stokes:Yeah. The point was raised about roll call. Let's see.
stokes: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.
Carl Beekhuizen: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.
Carl Beekhuizen:I mean, we could. I can also.
stokes:You can just reach out.
Carl Beekhuizen:But local chats. Yeah.
stokes:Get any input. But otherwise, yeah, I think.
stokes: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.
stokes:That seems fine to me.
stokes:yeah, unless anyone has any comments on this right now, we can just take further discussion to the Pr, there
stokes:and then. Yeah, we'll reach out Async to different parties.
stokes:See what works for them.
stokes:Okay, let's see. So I think that was everything we had for Fusaka. We discussed timelines.
stokes:And yeah, we're essentially halfway, which leaves the back half of the call for Glamsterdam.
stokes: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.
stokes:I do think focusing on Fusaka is quite prudent.
stokes: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
Ansgar Dietrichs: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
Ansgar Dietrichs: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
Ansgar Dietrichs: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
Ansgar Dietrichs:and make the decisions there.
stokes:Yeah, I'm curious what other people think.
stokes: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.
stokes:But I think, given this, it does seem more prudent even to, you know. Delay
stokes:this segment segment by another 2 weeks. So the next Acdc.
stokes:Well, I think that we see if I had bal sort of conditional on what the Cl. Would do.
stokes:Mark.
ethDreamer (Mark):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
ethDreamer (Mark):I mean.
ethDreamer (Mark):not a lot has really changed other than getting community feedback. I think we've had all the information for quite a while now
ethDreamer (Mark):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.
stokes:Yeah.
ethDreamer (Mark):I I mean me personally, I would be against delaying this decision, because I think we almost could have made it last call.
stokes:Okay, let's get into it. Then.
stokes:So okay, there's a bit of a bridge Pr to discuss here.
stokes:This is looking at how we structure the slot and the spec and all the different sub intervals.
stokes: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.
Justin Traglia:Hi, again. So there's a consensus. Specs. Pr, that I would like to merge.
Justin Traglia:It deprecates the intervals per slot variable, and defines explicit durations for deadlines like the attestation deadline.
Justin Traglia:This Pr is an alternative to 3, 5, sorry at 3, 5, 10, which we discussed about a month ago.
Justin Traglia: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.
Justin Traglia: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.
Justin Traglia:Eip 7, 7, 8, 2, which is like the shorter slot times.
Justin Traglia:eip and epbs sort of depend on this.
Justin Traglia: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.
Justin Traglia:and that's pretty much it.
stokes:Yeah, that makes sense.
stokes:Are there any open questions we should touch on now.
stokes: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.
stokes:Right? Okay? So I mean, I, unless there's a concrete, ask on exactly when to merge this end.
stokes:I think all we're saying is sooner than after Fusaka, or, you know, soon with Fusaka.
stokes:So
stokes: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
stokes:eips, and the consists repo that this would use. So
stokes:I know we're busy with Osaka, but if you have a moment, please take a look and provide feedback on the Pr.
stokes:okay?
stokes: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
stokes:from 8th magicians.
stokes:Nexo.
nixo:Hi, so I'm gonna put this link in the chat. Sorry for those who hate ocean. But
nixo:so basically, I focused on the the top
nixo:eips that were talked about in the stakeholder feedback, and I just wanted to call out
nixo:some of the feedback so that we're not having them
nixo:speak into the void here. But
nixo: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
nixo: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.
nixo:There were, there was a lot of support for 7, 8 0. 5 fossil
nixo: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.
nixo: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.
nixo: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.
nixo: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
nixo:But most of the other supporters cited sort of ideological or indirect
nixo: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.
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.
stokes: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.
stokes:Okay?
stokes:If not, then we had a request for an update on fossil from Jihoon
stokes:is Jihoon on the call.
Jihoon:Yes, I'm here.
stokes:Okay.
Jihoon:Mind if I share, screen.
stokes:Sure. Yeah. Please.
Jihoon:Alright. Can you guys see this? Okay?
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.
stokes:Yeah, I can.
stokes:Don't delay, Dolly.
Jihoon:Thank you. I guess I could use like 7 next 8 min. So Hello! I'm Jill. I'm working on fossil.
Jihoon: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
Jihoon: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.
Jihoon:So from Beacon Committee members with borrowed 16 validators to constitute Inclusionist Committee
Jihoon:Inclusion List committee members construct dials and broadcast it over the Prp network.
Jihoon:But testers and builders collect the Ils and builders update their payload to include Il transactions
Jihoon: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.
Jihoon:Now let's take a look into how it can be implemented.
Jihoon:The 1st validators can figure out if they have inclusion, inclusion, committee assignment by running this function.
Jihoon: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.
Jihoon: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.
Jihoon:And then a validator receives the Ils.
Jihoon: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.
Jihoon:But we don't have any selection mechanism. We just ignore it for that slot. So technically, the quivocator can just normally produce Ils.
Jihoon:Next time
Jihoon: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.
Jihoon:When our testers receive a block and run new, payload
Jihoon: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.
Jihoon:we want to block the reorg, so the block would get the proposer boost, and
Jihoon:if it's not, I am satisfied, then our testers will not for vote for the block, and proposals will not extend it.
Jihoon:So
Jihoon: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.
Jihoon: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.
Jihoon:Then they can select the bid. However, they want
Jihoon:the bit. Il bit list, construction and comparison can be implemented like this, for example.
Jihoon:but it's quite straightforward. So I think we can just move on.
Jihoon: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.
Jihoon:When the execution payload for slot n. Minus one arrives, we validate, if it contains ir transactions
Jihoon:in this example, let's say that it fails to satisfy the ir constraints because it doesn't have transaction. Y. For whatever reason
Jihoon:we will mark this payload as not ir compliant.
Jihoon: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.
Jihoon:but the payload was not ir compliant.
Jihoon:Whether the payload was timely, timely or not doesn't matter.
Jihoon: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.
Jihoon:and this can be implemented in 2 steps 2 steps because of the separation of become block and execution payload.
Jihoon:When the execution payload arrives. It works the same with vanilla fossil. The Cl. Relies on the el for the il validation.
Jihoon: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.
Jihoon:Other cases. Follow the Pbs back
Jihoon: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.
stokes:Yeah, justin.
Justin Florentine (Besu):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
Justin Florentine (Besu):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:So
Jihoon: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.
Jihoon: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
Jihoon:it was affordable.
Jihoon:I mean, if the transaction can afford the transaction.
Jihoon: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 (Besu):Okay. Thank you.
stokes:Okay, there are some comments in the chat about the agenda.
stokes: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.
stokes:There's 1 more request to hash. Give a short update on 6 second slots.
stokes: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
stokes:that's where this is heading.
stokes: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.
stokes:So anyway, I think Maria wanted to share a quick update. Let's do that.
stokes:Then we will go to the headliner selection.
Maria Silva:Right? Thank you. So I just quickly share my screen. This should be
Maria Silva:fairly quick. So I just wanted to have an update on some of the numbers that I shared last time.
Maria Silva: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.
Maria Silva: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.
Maria Silva: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.
Maria Silva:so it seems like we can do the block propagation in under one second.
Maria Silva: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?
Maria Silva: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.
Maria Silva:And we were seeing that initially, a a big part of the late arrivals were due to a few entities.
Maria Silva: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.
Maria Silva: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
Maria Silva: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
Maria Silva: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.
Maria Silva: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
Maria Silva:working towards a good.
Maria Silva: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.
Maria Silva:If not, I will just stop sharing.
stokes:Great thanks.
stokes: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.
stokes:Okay.
stokes: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.
stokes: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.
stokes:and it seems like there. That was also the selection as well, essentially. Pps. So
stokes:I think you know, what I propose is, we go ahead and Sfi. 7, 7, 3, 2 for Amsterdam.
stokes:I thought we were essentially waiting for this decision to like simultaneously, Sfi
stokes:es on the El. But either way we can figure that out.
stokes:But yeah, basically have those 2 as our Cl and Eo headliner.
stokes:and that unlocks the 1st step of glens RAM scoping.
stokes:So.
stokes:I suppose we can discuss the decision, but it seems like this is a crowd consensus mark.
ethDreamer (Mark):So
ethDreamer (Mark):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
ethDreamer (Mark):how highly the community does seem to value fossils. I think.
ethDreamer (Mark):like, I think last call the consensus was towards Epbs for the Devs. We just don't have very good visibility on how
ethDreamer (Mark):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
ethDreamer (Mark):I would also Cfi fossil. That would be my vote for now and and like
ethDreamer (Mark):inclusion of Cfi involved.
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
stokes: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
stokes: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.
stokes:we should work on those. And yeah, over the coming weeks we can have a conversation about other eips to put in there.
stokes:That gives us more time to validate these questions around, yeah, how does fossil exactly fit other Pps like, is it a good idea?
stokes:And all of those types of concerns?
stokes:Okay, Marcus, here. First, st was your hand there from earlier.
stokes: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
soispoke: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
soispoke:normal or like process wise to just like
soispoke:bump it, and just like treat it as like a normal eip without additional consideration. I think
soispoke: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
soispoke: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.
soispoke: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.
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.
stokes: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
stokes:around, yeah, interactions with us and any other complexities that could come up there.
stokes:Potus and the Barnabas.
potuz:So if epbs is specified and every single client
potuz:voiced to have fossil in it and the community, most of the community asked to have fossil with it.
potuz: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.
ethDreamer (Mark):Agreed.
stokes:Okay, Barnabas, I think this is going to be your counter comment, Otis.
Barnabas: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
Barnabas: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.
stokes:Yeah, I mean, I wouldn't get too hung up on the exact semantics of headliner.
ethDreamer (Mark):I think it was just about how much like a headliner is somewhat by definition, a very large change, and maybe due to synergies.
ethDreamer (Mark):You might consider fossil, not as large as it would otherwise be.
ethDreamer (Mark):I think that's really the the difference in terminology here. It's not anything
ethDreamer (Mark):more than that, as far as I can tell.
stokes:Right, like whatever goes in, we'll go in, and we just still need to decide what is the right scope.
stokes: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
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Ansgar Dietrichs: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
Ansgar Dietrichs:pick their own scope here.
stokes:Parents Terrence.
terence:Yeah. So I'm probably the only person in this world that implemented both epbs
terence: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.
terence: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
terence: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.
terence:So yeah, so I think, like.
terence: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?
terence:That's just my 2 cents.
stokes:Mark.
ethDreamer (Mark):I guess.
ethDreamer (Mark):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
ethDreamer (Mark):if it just means that if it doesn't mean that it's like in the spec. Yet.
ethDreamer (Mark):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
Justin Traglia:to Amsterdam.
ethDreamer (Mark):Okay? So at that point, we're not actually making the decision today to Cfi doesn't introduce any delay.
stokes:That's correct.
stokes: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.
stokes: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
Justin Traglia: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
Justin Traglia:pretty much.
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
stokes:that'd be the hope.
stokes:Yeah, okay, I mean, I think on square will get as strong a commitment as as possible.
stokes: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.
stokes:Nobody wants to commit there. There's some chatter over here in the chat.
stokes:But any case, we are coming up on time.
stokes:and I think we have enough to move forward, so we'll ssify 7, 7, 3, 2,
stokes:we will see if I fossil.
stokes:and that will be it for Glamsterdam today on Square.
Ansgar Dietrichs:Yeah, I want to make one last push against
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs:I would personally
Ansgar Dietrichs: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.
ethDreamer (Mark):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.
ethDreamer (Mark):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
ethDreamer (Mark):basically, how many months there are between.
ethDreamer (Mark):So
ethDreamer (Mark):I I mean, as of right now. Yeah, we don't know how long it's gonna take the El to implement
ethDreamer (Mark):block level access lists. And when they're gonna be ready, but
ethDreamer (Mark):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
Ansgar Dietrichs: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
Ansgar Dietrichs:track towards a unified glam set up that works for me.
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.
stokes:So we should be focusing on that. And yeah, I think this lets us make some progress on classroom, which is good.
stokes:I also think it's quite early to
stokes:have a super clear sense of okay, these exact timelines and what that will look like. So
stokes:again, Cfi, sorry. Sfi, 7, 7, 3, 2 cfi fossil
stokes:that settles the discussion today, and that gives us more to move on with.
stokes:Otherwise, yeah, we will be talking about slash working on for Saka.
stokes:Any closing comments otherwise. I'll see many of you on a call Monday.
potuz:Bye.
stokes:Thanks. Everyone.
Pooja Ranjan:Do.
stokes:Bye.
ethDreamer (Mark):Hey, guys.
Chat Logs
00:04:04
stokes:https://github.com/ethereum/pm/issues/1638
00:07:19
Parithosh Jayanthi:https://discord.com/channels/595666850260713488/892088344438255616/1402246314187690217
00:09:36
nixo:https://notes.ethereum.org/@jtraglia/fusaka_scheduling
00:13:27
Ahmad Bitar | Nethermind:I would not push the blobs higher before we have slot restructuring
00:13:39
Barnabas:Devnet 4:
BPO_1_MAX_BLOBS=14
BPO_1_TARGET_BLOBS=9
BPO_2_MAX_BLOBS=21
BPO_2_TARGET_BLOBS=14
BPO_3_MAX_BLOBS=32
BPO_3_TARGET_BLOBS=21
BPO_4_MAX_BLOBS=48
BPO_4_TARGET_BLOBS=32
BPO_5_MAX_BLOBS=72
BPO_5_TARGET_BLOBS=48
00:13:48
Francesco:Replying to "I would not push the..."
Higher than?
00:13:54
Ben Edgington:More compressed = less time to observe, and less time to respond. Need to allow time for hf/deployment in case of trouble.
00:14:15
Tim Beiko:Replying to "More compressed = le…"
3 weeks feels like the minimum we should have them apart
00:14:35
Anders Elowsson:Maybe we should consider targets that when multiplied with (3/2) gives an integer limit?
00:14:47
Anders Elowsson:i.e., 10/15, etc
00:15:07
Ahmad Bitar | Nethermind:Replying to "I would not push the..."
I mean, i would space them out more so that the high numbers only ship after slot restructuring
00:15:14
potuz:Replying to "More compressed = le..."
I think in addition to these we need to account for the usual delay in actually blob space and usage catching up. It hasn't been immediate in the past
00:15:42
Ahmad Bitar | Nethermind:Replying to "I would not push the..."
Is the bandwidth requirement for validators taken into account here when we are pushing those?
00:16:11
Barnabas:I’d like to add that scheduling an extra BPO fork should be very easy.
00:16:16
Francesco:Replying to "More compressed = le..."
We can spam mainnet to see high blob throughput regardless of real usage (as long as the 21k fee isn’t prohibitively high)
00:16:35
Parithosh Jayanthi:For p2p stuff, mainnet data is kind of the only data that really matters. Any testing data just helps us derisk.
00:16:40
potuz:Replying to "More compressed = le..."
+1
00:17:26
Parithosh Jayanthi:Replying to "More compressed = le..."
This is the plan
00:17:34
Parithosh Jayanthi:Replying to "More compressed = le..."
I’ve been told “budget approved” 😄
00:18:22
pk910:Replying to "More compressed = le..."
rly? we gonna do mainnet blob spmming?? lol
00:18:41
stokes:Replying to "More compressed = le..."
yes
00:19:54
Phil Ngo:I’d like to add that we’re also currently reviewing >10,000 lines of code to merge this onto our unstable.
00:20:22
Manu:Prysm has also >4k lines of code yet to merge into our unstable branch
00:20:36
Ansgar Dietrichs:There should obviously never be hesitancy to voice concerns on here
00:20:44
Dustin:Replying to "I’d like to add t..."
Nimbus has also not fully reviewed the code being merged from the fusaka-devnet-3 branch, yeah
00:20:51
Barnabas:Can you guys propose an alternative timeline?
00:21:02
Ansgar Dietrichs:Is this mostly about CL peerdas implementations?
00:21:09
potuz:can we split the discussion instead of delay/no delay to perhaps an option of forking Holesky without master branch releases?
00:21:25
ethDreamer (Mark):PR CONGA LINE
00:21:30
ethDreamer (Mark):You guys have to try it
00:21:45
ethDreamer (Mark):Split forks up into multiple PRs on top of each other
00:21:54
Tim Beiko:Replying to "Prysm has also >4k l…"
Does Prysm also need +4 weeks or so for this?
00:22:01
kingy_sigp:Lighthouse are fine with a four week delay if that gets everyone aligned and stable
00:22:04
ethDreamer (Mark):Then merge into unstable one piece at a time
00:22:09
Manu:One solid devnet with >90% private mempool (so without getBlobsv2)
00:22:15
Barnabas:we have been doing private mempool testing
00:22:20
Stefan Bratanov:Teku has been on master for a while now, but we have been through a pain of merging, so I understand the proposed delay
00:22:21
Manu:Replying to "we have been doing p..."
What’s the percentage?
00:22:23
Parithosh Jayanthi:Note: fusaka-devnet-3 has private mempool testing
00:22:32
Barnabas:Replying to "we have been doing p..."
100%
00:22:42
Barnabas:Replying to "we have been doing p..."
there are bugs with the private mempool propagation
00:22:44
Barnabas:Replying to "we have been doing p..."
but thats another topic
00:22:50
Manu:Replying to "we have been doing p..."
https://dora.fusaka-devnet-3.ethpandaops.io/mev/blocks
00:22:56
Justin Traglia:If we delay by ~1 month, it’s likely going to be delayed by 3 months because of holidays.
00:23:01
Barnabas:Replying to "we have been doing p..."
its not running now
00:23:05
Parithosh Jayanthi:Replying to "we have been doing p..."
Yeah non finality since the morning
00:23:05
Tim Beiko:Would be good to hear from Prysm + Nimbus a bit more!
00:23:06
Barnabas:Replying to "we have been doing p..."
But we had days of spamming
00:23:09
Parithosh Jayanthi:Replying to "we have been doing p..."
Check data from ~2d ago 😄
00:24:26
Matthew Keil:Replying to "Is this mostly about..."
Yes
00:25:11
Parithosh Jayanthi:E.g: https://dora.fusaka-devnet-3.ethpandaops.io/slot/106243
00:26:02
potuz:Blobs were comming regularly on all blocks with the expected throghput @Parithosh Jayanthi ? or some were with zero regularly
00:26:06
Ansgar Dietrichs:I am a bit surprised, two speakers raising need for testing without getBlobsv2, sounds like that has been happening for weeks already, so is this more a case of lack of communication?
00:26:20
Ansgar Dietrichs:Replying to "I am a bit surprised…"
Or is this about different tests?
00:26:25
potuz:no, this was a request for a long time Ansgar
00:26:39
J Sunnyside Labs:Sunnyside Labs, we also tested without getblobsv2 and saw about ~15% less blob throughput (though it has been a while)
00:26:53
potuz:this was already specified as a hard requirement to set a timeline before the previous ACDC
00:26:56
Parithosh Jayanthi:Replying to "Blobs were comming r..."
We did random checks and they were stably included, but we can come back with an inclusion analysis to see how much worse it gets without getblobsV2
00:27:12
Ansgar Dietrichs:So main concern is more about code readiness for releases? Makes sense
00:27:16
Phil Ngo:Replying to "I am a bit surprised..."
I think we also need to take into account the engineer’s confidence in their code. Otherwise tech debt gets merged in with it. We’re doing a lot of cleanup on hacky code that was done to make things work for devotes.
00:27:29
Phil Ngo:Replying to "I am a bit surprised..."
*devnets
00:27:51
potuz:Replying to "Blobs were comming r..."
If they were relatively regular that's alredy good enough. The mempool being purely private is not reallistic anyway
00:28:34
Parithosh Jayanthi:Replying to "Blobs were comming r..."
Yeh, there’s a tx propagation bug in reth/rbuilder - but it’s unrelated to blobs or peerDAS in itself. Just makes the data messier. We’ll get back with proper data once bugs are patched.
00:30:32
Barnabas:There was more time, which means that pectra was also delayed by like 3 months compared to initial target
00:31:07
Ansgar Dietrichs:Okay, right, it is what it is, if these concerns exist, we can’t ignore them.
Of course "Fusaka pre Devconnect" has been a big goal - is there any world to allow for more time while still keeping the possibility of that alive? Say 2-4 weeks delay, and cutting out some weeks somewhere in our timeline from first releases to mainnet fork?
Just asking, not pushing for that
00:31:10
Tim Beiko:If we delayed by 4 weeks, we could still ship in December, but we should consider what our go/no-go criteria are
00:32:16
potuz:I think delays for master releases can be made semi-independent of releases for testnests. Specially Holesky for example
00:32:26
potuz:so that the final delay is not so bad as the proposed 4 weeks
00:32:28
Barnabas:I personally think the main issue is that we didn’t have enough engineering time allocated to fusaka, especially in smaller client teams.
Ideally we need main senior engineers working on fork + 1, and allocate less resources on fork + 2 or fork + ?.
If we had more engineers working on fusaka full time, we could have shipped 1st of Sep.
00:32:39
Tim Beiko:Replying to "I think delays for m…"
Maybe for Holesly, but IMO live testnets should get proper releases
00:33:15
Tim Beiko:Yes, would be curious to understand this better, esp. given it shows up across multiple teams
00:33:17
Parithosh Jayanthi:Could we do Holesky in September so it isn’t on the critical path? With non trunk releases
00:34:17
Dustin:Replying to "Could we do Holesk..."
non-trunk releases are a challenge for Nimbus. I mean, sure, we can point to a non-canonical release, but typically Nimbus doesn't do "testnet-only" releases
00:34:39
potuz:Replying to "Could we do Holesky ..."
how are you running on devnet-3?
00:34:44
potuz:Replying to "Could we do Holesky ..."
is it master?
00:34:50
Dustin:Replying to "Could we do Holesk..."
it's a branch
00:35:00
potuz:Replying to "Could we do Holesky ..."
yeah that's what I mean for Holesky
00:36:12
Chris:Replying to "Could we do Holesk..."
I think this could end up being a pointless exercise. If we don't get full participation any bugs could get hidden in the noise. I have low confidence of getting full participation from all node operators if the releases are all on branches.
00:36:40
Barnabas:we can aim to do a devnet 5 for 2nd sep
00:36:44
Barnabas:that runs a week
00:36:49
Ansgar Dietrichs:Can we get individual weeks from different places? Say 2 weeks by cutting down the delay between last testnet and mainnet, 2 weeks for not using master for Holesky, etc? Maybe we atill had a week of buffer pre devconnect as well?
So not just push everything back a month
00:37:15
potuz:Replying to "Could we do Holesky ..."
yeah my impression is that Holesky will be a non-finality test on the current code
00:38:07
Justin Florentine (Besu):sounds pectraey
00:38:59
Dustin:Pectra got oops-delayed by another 1.5 months or so, maybe 1 month, by insufficient testing, as it happened
00:39:09
Dustin:it was not a case of moving too slowly
00:40:07
Ansgar Dietrichs:We could explore different timeline adjustments and make a decision on ACDT?
00:40:19
Justin Florentine (Besu):was referring to the suggestion of testing early nets from non-merged-to-trunk clients. sounds like a good way to mis config opts, such as what complicated pectra
00:40:22
Francesco:One thing is readiness, testing etc… but let’s not create requirements that don’t need to be there, e.g. syncing in perfect peerdas when there’s literally no peers you could even theoretically get your data from
00:40:25
Manu:Holesky in September: Prysm ok
00:40:35
Dustin:Nimbus ok too
00:40:46
Matthew Keil:Hole sky sept: lodestar is ok
00:40:52
kingy_sigp:Lighthouse are OK
00:41:14
Ansgar Dietrichs:But of course, even with the latent eth/acc vibes this year, safety always comes first
00:41:23
pawan:Replying to "One thing is readine..."
Strong agree. Its a very contrived scenario
00:41:44
Chris:I think it would be worth getting a temp check on Holesky validators TG that participants are happy to run non-releases on Holesky in September.
00:41:50
potuz:Replying to "One thing is readine..."
I think the testing on perfect peerdas is not so much about syncing but just gossiping working
00:42:24
Fredrik:Regarding the audit competition then, should we do that earlier on the holesky code or wait until later?
00:42:28
Ansgar Dietrichs:Then I would propose not having Glamsterdam headliner discussion today. Premature. All focus Fusaka.
00:42:31
potuz:Replying to "One thing is readine..."
because smaller testsnets don't have the bandwitdh issue of propagating blobs when the mempool is slower and is fully propagated
00:42:41
stokes:https://github.com/ethereum/pm/issues/1638#issuecomment-3161024180
00:42:43
Francesco:Yeah testing is fine, just referencing the discussion on Monday about genesis syncing, which would need full nodes to go and try to grab 64 columns to reconstruct
00:42:46
potuz:Replying to "One thing is readine..."
so it's imperative to test in a scenario where nodes can't get all blobs from the EL
00:42:46
pawan:Replying to "One thing is readine..."
I agree gossip should work. Syncing is crazy given it takes 2 seconds to reconstruct blobs for a single block
00:42:51
Tim Beiko:More of a process thing, but IMO it would have been more productive for each team to individually voice this async ahead of the call. We should minimize the element of surprise in these things as much as we can.
00:42:51
Barnabas:Replying to "Regarding the audit ..."
maybe we can gate it to clients that have releases?
00:43:19
terence:has the api been discussed in the RollCall?
00:43:45
potuz:Replying to "One thing is readine..."
Problem is that if we get a bug in which an entire client needs to restart and sync, this starts to be critical
00:43:57
nflaig:https://github.com/ethereum/beacon-APIs/pull/546
00:44:34
Fredrik:Replying to "Regarding the audit ..."
I’ve been thinking the same, but then the issue is that we will have clients which devs/users may not feel as confident about
00:44:43
terence:ah ok, at least mention in the eth R&D discord then, RollCall channel
00:44:53
Carl Beekhuizen:Replying to "ah ok, at least ment..."
Yeah, exactly
00:45:13
nflaig:Replying to "ah ok, at least ment..."
there is a thread in api channel in R&D discord
00:45:29
nflaig:Replying to "ah ok, at least ment..."
https://discord.com/channels/595666850260713488/1399322034273521797
00:46:15
terence:Replying to "ah ok, at least ment..."
for sure, but RollCall channel is bridged via telegram with the L2 devs, just not sure if they pay attention to the api channel
00:46:36
nixo:+1
00:47:05
Justin Florentine (Besu):EL devs already CFId BAL for Glamsterdam taps watch
00:47:22
nflaig:Replying to "ah ok, at least ment..."
let me share it there as well
00:47:29
Barnabas:I’m really not in favor of pushing decision making on headliners by another 2 weeks
00:47:34
potuz:In two weeks we will have about 10 different proposals as alternatives for ePBS
00:47:37
Justin Traglia:I think now is the time to decide
00:47:40
Justin Florentine (Besu):same. not sure what we'd do the time?
00:47:44
potuz:we are getting one more per day
00:47:45
Felix (Geth):I don't think we have 'conditionally' CFId BALs.
00:47:49
potuz:this is becoming ridiculous
00:48:01
Felix (Geth):We have CFId it period
00:48:23
Barnabas:Ansgar is in holiday mood?
00:48:24
Barnabas:😂
00:48:27
Justin Traglia:https://github.com/ethereum/consensus-specs/pull/4476
00:48:28
stokes:https://github.com/ethereum/consensus-specs/pull/4476
00:48:46
Ansgar Dietrichs:Replying to "Ansgar is in holiday…"
I’m in Fusaka shipping mood
00:49:45
terence:Lgtm
00:49:53
Barnabas:Replying to "Ansgar is in holiday..."
the two are independent of each other
00:49:56
pawan:Lighthouse in favour too
00:50:02
Barnabas:Replying to "Ansgar is in holiday..."
and we realistically need to start testing epbs this month
00:50:15
Barnabas:Could you guys thumbs up the PR then?
00:50:46
Justin Traglia:Yes, maybe within a week or two?
00:50:59
potuz:7805
00:51:19
Barnabas:Replying to "Yes, maybe within a ..."
lets aim to merge it by next acd?
00:51:20
Trent:In case anyone hasn’t seen, FB followed up with part II of their free option problem in ePBS
https://collective.flashbots.net/t/the-free-option-problem-in-epbs-part-ii/5145
00:51:21
potuz:7732+7805+7782 depend on it
00:51:30
nixo:https://efdn.notion.site/Stakeholder-feedback-synthesized-247d9895554180048a8bd279a28798a1
00:51:36
Stefan Bratanov:Replying to "Lighthouse in favour..."
likewise for Teku!
00:52:32
potuz:This is a short summary of that thread's direct voting
00:53:53
terence:Saw... protocol research & design (Nethermind) had a vote... Could protocol research & design (Prysm) add a vote too? : )
00:54:20
Barnabas:Replying to "Saw... protocol res..."
prysm already had a “vote“
00:54:32
ethDreamer (Mark):Replying to "Saw... protocol res..."
Only if lighthouse research and design can vote too :p
00:54:34
potuz:Replying to "Saw... protocol res..."
so did Nethermind, that's the point
00:55:25
Lin Oshitani | Nethermind:Replying to "Saw... protocol res..."
Note that Nethermind research is independent from Nethermind client team (we are 300ppl company), and that post was written independently too.
00:55:26
Justin Florentine (Besu):thanks nixo, and thanks for capturing the nuance about FOCIL prefs
00:55:41
potuz:Replying to "Saw... protocol res..."
Terence was obviously joking
00:56:23
Ansgar Dietrichs:I personally think the EL features in Glamsterdam are the most important (BALs plus repricing). I would personally want us to have a clear decision that we ship whatever is ready by March, even if that would e.g. mean kicking the CL headliner back out.
00:56:23
Lin Oshitani | Nethermind:Replying to "Saw... protocol res..."
Ah, ok 😅
00:56:56
potuz:BALs become much more of a tradeoff without ePBS
00:57:06
potuz:with 30% larger blocks
00:57:14
Ansgar Dietrichs:Replying to "I personally think t…"
Basically, have an interop in March, and kick out anything that is not clearly within weeks of RC readiness by the end of interop.
00:57:38
Justin Florentine (Besu):Replying to "I personally think t..."
or just decouple the forks
00:58:08
potuz:Replying to "I personally think t..."
that's how Verkle never happened, exactly this way
00:58:51
Sophia Gold:IIUC ePBS increases execution throughput more than BALs so I would say the CL is much more important for Glamsterdam and we should not delay it
00:59:00
Justin Florentine (Besu):Replying to "I personally think t..."
idk why March is significant?
01:02:12
Anders Elowsson:Just a note that we do not wish to add the IL bitfield to the bid unless attesters are going to vote on it. If the PTC votes on it, the builder need not include the bitfield in the bid.
But I do think we should pursue the ABB design.
01:02:17
Justin Florentine (Besu):the notion of "would have fit" is interesting
01:02:51
Justin Florentine (Besu):Replying to "the notion of "would..."
does that imply re-execution?
01:02:53
Ansgar Dietrichs:Wait we are only making headliner decision today, right? Is it not obvious that we will not make FOCIL a solo headliner already?
Even if we want to consider combining it with ePBS, process would be only selecting ePBS as headliner today, and then consider FOCIL in the "normal EIP" stage in the next calls, no?
01:03:07
terence:it's not clear to me where this is going, are we deciding glamsterdam CL headliner today?
01:03:13
stokes:Replying to "it's not clear to me..."
yes
01:03:19
stokes:Replying to "it's not clear to me..."
But some requests for input
01:03:22
soispoke:Here’s also a high level write up about ePBS and FOCIL compatibility if people are interested: https://ethereum-magicians.org/t/epbs-focil-compatibility/24777
And there was also a discussion + presentation on the last FOCIL breakout session: https://www.youtube.com/watch?v=gjWReOSaT-o
01:03:41
Ansgar Dietrichs:Replying to "Wait we are only mak…"
As in, we should make decision against FOCIL as headliner asap, and then put it put of scope for today.
01:04:01
stokes:Replying to "Wait we are only mak..."
I think its part of the epbs decision
01:04:08
stokes:Replying to "Wait we are only mak..."
And if we want FOCIL as a non-headliner it is also relevant
01:04:24
ethDreamer (Mark):This is a (premature) PR of FOCIL on top of 7732:
https://github.com/ethereum/consensus-specs/pull/4493
01:04:29
potuz:can we move on to headliner decision that was what we have agreed to do many weeks ago, and then have these discussions? I am a bit mind blown by the ordering of this meeting
01:04:44
terence:I feel like FOCIL technical discussions is better suited in ACDT or bi weekly FOCIL breakout
01:04:48
ethDreamer (Mark):Replying to "This is a (premature..."
^ consensus-specs
01:05:07
Ansgar Dietrichs:Replying to "Wait we are only mak…"
non-headliners are not today though
01:05:28
Jihoon:Slides: https://docs.google.com/presentation/d/1KmRsdpDNQpxOlWF0ThqZNRTBDWMV8RuCNLsMjDf9XRo/edit?usp=sharing
FOCIL for CL: https://hackmd.io/@jihoonsong/rJX-fxADxl
FOCIL for EL: https://hackmd.io/@jihoonsong/BJpcaudvex
01:06:23
Ansgar Dietrichs:Replying to "I personally think t…"
Just throwing out a date, point is more, I personally would not want to delay the fork for a headliner
01:06:24
potuz:ohhh that's much better
01:06:51
terence:yay
01:07:04
soispoke:Replying to "Wait we are only mak..."
But FOCIL is in a bit of a weird place because it has received broad support from the community as a headliner already
01:07:06
potuz:yeah that's the number we were using internally too, it's good news
01:07:27
soispoke:Replying to "Wait we are only mak..."
So it has a bit of an in between status I think it’s worth discussing
01:07:34
Ansgar Dietrichs:Replying to "Wait we are only mak…"
I am open to considering it instead of ePBS still
01:07:46
Ansgar Dietrichs:Replying to "Wait we are only mak…"
Just doesn’t seem like a realistic outcome
01:08:27
Justin Florentine (Besu):Replying to "Wait we are only mak..."
FOCIL + ePBS is more realistic than FOCIL instead of ePBS
01:08:29
soispoke:Replying to "Wait we are only mak..."
I mean this is a discussion that can also happen (but I also think it’s unlikely)
I would say these are two separate conversations to have
01:10:31
Francesco:🥁🥁
01:10:33
Sophia Gold:If we're potentially SFIing ePBS today, I think it would be good to have a discussion of the dual deadline and impact of changing it. Including a tldr of how much execution time is added, how much blob propagation time is added with the current design, how much if the blob deadline is moved, and extrapolation to additional blob throughput
01:10:48
Jihoon:Replying to "I feel like FOCIL te..."
I think it could be useful information for people who couldn't afford to take a look into it.
01:10:49
Toni Wahrstätter:I think no big CL feature should be added on top of ePBS. It alone touches enough major parts of the protocol and should be shipped in isolation to other changes, especially those affecting fork choice.
Max., have focil as a strech goal but kick it if it would delay the fork.
01:11:16
Caleb:If we're potentially SFIing ePBS today, I think it would be good to have a discussion of the dual deadline and impact of changing it. Including a tldr of how much execution time is added, how much blob propagation time is added with the current design, how much if the blob deadline is moved, and extrapolation to additional blob throughput
probably bst suited for the testing call
01:11:30
potuz:Replying to "If we're potentially..."
I do think these timelines need to be computed and benchmarked precisely to be set
01:11:31
soispoke:Replying to "I think no big CL fe..."
That was basically what I wanted to propose, just waiting for the sort of ePBS verdict first
01:11:48
potuz:Replying to "If we're potentially..."
and as the flashbots guys pointed, it's imperative to have a way to adjust them at runtime specially with BPOs
01:12:16
Jihoon:Replying to "If we're potentially..."
Does T stand for technical? 😂
01:12:17
potuz:Replying to "If we're potentially..."
but those are technical details of adjusting a single constant in the spec riather than something to be discussed in ACD at this stage I believe
01:12:19
Toni Wahrstätter:Replying to "I think no big CL fe..."
The default should then be to include in on a devnet as late in the process as possible to not risk big work from removing it
01:12:33
potuz:+1 from me, not discussed with PRysm
01:12:48
potuz:I was like Barnabas 4 weeks ago, SFI ePBS CFI FOCIL
01:12:48
Sophia Gold:Replying to "If we're potential..."
Can you estimate the additional execution time? This shouldn't be changing and I feel like I should already know it
01:12:53
Justin Florentine (Besu):love it, and would be open to trying FOCIL and boot if it threatens ePBS
01:13:06
Ansgar Dietrichs:I would strongly request we stick to process and do not CFI any non-headliners today
01:13:11
Toni Wahrstätter:How realistic is it that we realize focil and epbs are too big and suddenly removing focil would impact epbs and the "pulling out" turns more complex as thought
01:13:32
potuz:Replying to "If we're potentially..."
I think with current numbers of propagation we should get at the very least 8 seconds execution for proposers and 10 seconds exectuion for attesters
01:13:33
Ansgar Dietrichs:Replying to "I would strongly req..."
but I do think having FOCIL as a stretch goal EIP is a reasonable idea
01:13:35
Justin Florentine (Besu):FOCIL is kind of a co-headliner in this case.
01:14:05
Barnabas:FOCIL was proposed as a headliner. Making a decision about it today is the right place imo.
01:14:07
Anders Elowsson:If the PTC_P point stays the same, there is no additional execution time added. Removing the dual deadine would only put some optimisation pressure toward reducing execution time
01:14:08
stokes:I think we should derisk this before putting it in
01:14:13
potuz:Replying to "If we're potentially..."
this is assuming that we keep the current design and not trade off on the free option problem
01:14:21
stokes:Replying to "FOCIL was proposed a..."
It is not a headliner
01:14:22
Ansgar Dietrichs:Replying to "FOCIL was proposed a..."
well then the decision is no
01:14:26
stokes:Replying to "FOCIL was proposed a..."
But can still be in glamsterdam
01:14:36
terence:Replying to "FOCIL was proposed a..."
when do we decide that?
01:14:50
Sophia Gold:Replying to "If we're potential..."
@Anders Elowsson I mean vs. current execution time
01:15:06
stokes:Replying to "FOCIL was proposed a..."
Soon (tm)
01:15:06
Ansgar Dietrichs:“slows down the fork” - that must include slowing down the EL side of the fork though, otherwise ePBS and FOCIL as a batch will just delay and slow down the EL
01:15:12
Barnabas:Replying to "FOCIL was proposed a..."
how is it not a headliner? Its a huge change on its own.
01:15:20
Tim Beiko:How about we SFI EPBS + BALs, CFI FOCIL, and make a SFI decision for FOCIL once we are further in the development process and know what we are comparing FOCIL with?
01:15:34
terence:Replying to "How about we SFI EPB..."
makes sense to me
01:17:04
Tim Beiko:^ this means glamsterdam-devnet-1 is EPBS + BALs, then devnet-2 could include FOCIL
01:17:16
potuz:I agree, semanthics are irrelevant
01:17:19
Francesco:How are we saying this after talking about delaying Fusaka an hour ago 😅
01:17:25
Eitan:FOCIL changes are along similar code paths that ePBS is already changing. There is some development synergy here
01:17:30
soispoke:The broader point is not to exclude EIPs with broad support based on semantics or strict process
01:17:41
Josh Davis:Headliner means not kicked out for fork delay
01:17:58
Justin Florentine (Besu):there is EL work for FOCIL, and capacity considering BAL
01:18:03
potuz:Replying to "How are we saying th..."
Good thing is that Glamsterdam doesn't have a timeline
01:18:07
Sophia Gold:The reason to not call FOCIL a headliner is that we don't want to block on it if it's not done when ePBS is. It's okay for it to be bumped one fork, but not more than that
01:18:31
potuz:Replying to "How are we saying th..."
I think it's worth to have FOCIL at the cost of having a larger fork, if it was any other feature I'd be happy to have ePBS and nothing else
01:18:42
Justin Florentine (Besu):Replying to "How are we saying th..."
because crypto twitter rips on us for not being "ambitious" enough.
01:18:46
potuz:Replying to "How are we saying th..."
FOCIL is really at risk to be now or never
01:18:46
Francesco:+1, if we start with epbs + focil it will never be separated without huge pain
01:19:13
Parithosh Jayanthi:Replying to "How are we saying th..."
Isn’t focil or something similar to it basically a MUST before zk-enshrining?
01:19:17
soispoke:Replying to "+1, if we start with..."
Devs that have worked on both said code changes are actually most orthogonal
01:19:30
stokes:Replying to "How about we SFI EPB..."
I would lean to not CFI just following the original post
01:19:37
Dustin:Replying to "How are we saying ..."
that's years from now, by usual timelines from lean
01:19:37
stokes:Replying to "How about we SFI EPB..."
But also seems fine
01:19:43
stokes:Replying to "How about we SFI EPB..."
To CFI today
01:19:48
Francesco:Replying to "How are we saying th..."
Why? Either way, we won’t enshrine zk in 2026
01:19:55
Jihoon:Replying to "+1, if we start with..."
I would like to learn what devs think about this
01:19:56
Dustin:Replying to "How are we saying ..."
3 years is the smallest credible number I've seen
01:19:58
Caleb:ePBS headlines while FOCIL supports, it's all about who you sync with
01:20:04
Sophia Gold:Replying to "How are we saying ..."
Not just for enshrining, for scaling with zk at all...
01:20:09
potuz:Replying to "+1, if we start with..."
I don't understand thje comment Francesco, if ePBS is already SFI, then we never are in a situation of needing to separate
01:20:15
Anders Elowsson:Replying to "If we're potentially..."
@Sophia Gold Aha sorry. Yes, as potuz mentioned then. We get S-PTC_P in execution time. So if we set PTC_P early, we gain more.
01:20:22
Parithosh Jayanthi:Replying to "How are we saying th..."
Which seems like we might start doing next year onwards
01:20:30
potuz:Replying to "+1, if we start with..."
there is no future of FOCIL without ePBS if it's actually SFId
01:21:01
Francesco:Replying to "+1, if we start with..."
The opposite, “if we are not managing to ship the fork in time we take focil out"
01:21:12
Sophia Gold:Replying to "How are we saying ..."
I think it's fine for it to be in H fork but not later. I'm sympathetic to arguments that deprioritizing it now means it won't happen in time
01:21:13
Trent:Replying to "How are we saying th..."
Any links about FOCIL <> zk?
01:21:15
Toni Wahrstätter:Replying to "+1, if we start with..."
The specs for both are still in progress, so, I wouldn't underestimate the complexity.
They interact, thus, removing one will be complex.
01:21:17
potuz:Replying to "How about we SFI EPB..."
Echoing this, Tim's comment is exactly my favorite fork
01:21:28
Ansgar Dietrichs:1-2 months delay over April would make me strongly oppose FOCIL fwiw
01:21:40
Sophia Gold:Replying to "How are we saying ..."
I touched on it in the RTP blog post
01:21:43
Justin Florentine (Besu):Replying to "How are we saying th..."
i actually think getting both in would be worth delaying (within reason)
01:22:28
Ansgar Dietrichs:if we accept FOCIL, we need to have super explicit agreement on process though.
“if it delays ePBS, we will kick it out” - that is not good enough, who makes that call, and when?
If we say we don’t wait for the CL headliner(s), then it is easy, then it is in the best interest of the ePBS champions to honestly track FOCIL delay concerns and act on them.
01:22:33
Francesco:Feels like everyone is being delusional again with the timelines because otherwise the EIP will not get included
01:22:52
Justin Florentine (Besu):Replying to "1-2 months delay ove..."
I would be fine with delaying to include both, up to about August
01:22:52
terence:i see no reason not to CFI focil today, we are not SFI'ing focil
01:23:01
Barnabas:Replying to "Feels like everyone ..."
good thing we are not talking about deadlines
01:23:10
potuz:Replying to "Feels like everyone ..."
what timelines?
01:23:24
potuz:Replying to "Feels like everyone ..."
there has been no talk on Glamsterdam timelines as we did for Fusaka
01:23:32
soispoke:Replying to "1-2 months delay ove..."
I think not considering broad community input and devs for a month delay would not be a good decision tbh
01:23:32
Ansgar Dietrichs:so would we get a strong commitment from all CL clients to not dedicate any work to FOCIL until ePBS is stable?
sounds like that is what Alex just proposed
01:23:42
potuz:Replying to "Feels like everyone ..."
I see Ansgar saying MArch, but ePBS will not be ready for March
01:23:46
potuz:Replying to "Feels like everyone ..."
not at all
01:23:49
soispoke:Replying to "so would we get a st..."
4 CL clients have already worked on FOCIL
01:23:54
Ansgar Dietrichs:Replying to "so would we get a st..."
that’s what I mean
01:23:55
potuz:Replying to "Feels like everyone ..."
with or without FOCIL
01:23:55
Dustin:Replying to "Feels like everyon..."
Francesco just talked about March/Apr
01:23:58
terence:Replying to "so would we get a st..."
prysm has working branch for both
01:24:05
potuz:Replying to "Feels like everyone ..."
no freaking way
01:24:11
Jihoon:Replying to "so would we get a st..."
Depends on CL client team I think. Some team can working on both in parallel like Lodestar
01:24:12
Dustin:Replying to "Feels like everyon..."
or Ansgar yeah
01:24:16
Francesco:Replying to "Feels like everyone ..."
I didn't?
01:24:19
Barnabas:Could I ask for dedicated CL engineers for glamsterdam scope? Same way as we did with peerdas.
01:24:20
Dustin:Replying to "Feels like everyon..."
oops
01:24:23
Jihoon:Replying to "so would we get a st..."
That's one of feedback I've gathered
01:24:27
Dustin:Replying to "Feels like everyon..."
Anyway, timelines are being discussed
01:24:43
Sophia Gold:Replying to "so would we get a ..."
You can't accelerate something just by putting more devs on it
01:24:49
potuz:Replying to "Feels like everyone ..."
no, there's no discussion, it's only Ansgar
01:25:08
Jihoon:Replying to "so would we get a st..."
Not talking about man month myth. I'm talking about 0 or not 0
01:25:29
Justin Florentine (Besu):idk why we're talking more about dates than fork composition
01:25:44
Sophia Gold:Replying to "so would we get a ..."
I was responding to Ansgar. They should have as many as necessary for ePBS, but there's a limit. Presumably not the whole team
01:25:46
Francesco:Replying to "so would we get a st..."
CL clients worked on PeerDAS for a year before Pectra shipped as well
01:25:47
Barnabas:if we doing EL only fork then why are we even talking about glamsterdam? That would be just Amsterdam.
01:26:13
Jihoon:Replying to "so would we get a st..."
PeerDAS had no stable spec back then. FOCIL has stable specs in any regard
01:26:17
Ansgar Dietrichs:okay so we would not wait for say 2+ months for the CL headliner(s)?
01:26:33
Jihoon:Replying to "so would we get a st..."
Sorry any regard is too much. I meant in CL, EL, engine API, rebase onto ePBS
01:26:41
Eitan:Replying to "so would we get a st…"
I don’t think peerdas is even a fair comparison it’s a much more complex change than FOCIL
01:26:59
Barnabas:There are plenty of work on ELs that can also delay a fork, if those repricing EIPs get included.
01:27:20
Barnabas:I’d not worry that EL would be ready so quick that they would be just sitting around .
01:27:38
Ansgar Dietrichs:Replying to "There are plenty of ..."
of course, good chance the EL is the one causing the delays.
Just talking about what if it’s the CL, and it’s a long delay
01:27:55
Justin Florentine (Besu):good work y'all