All Core Devs - Consensus #154

Transcript

Alex Stokes: Let's see. Josh, are you helping with the stream today.

Josh Davis: Yep ready when you are.

Alex Stokes: Okay, let's go and do it.

Josh Davis: You are alive.

Alex Stokes: Okay, thank you. Hello, everyone. This is Acdc, 1, 54. It is issue 1399 in the Pm repo. And yeah, we have a couple of things today. We'll start with Petra, then turn to pure dos. From there, go to essentially fausa inclusion. There are a number of other eips around pure dos that we can discuss. and we'll wrap up at the end if there's time with a number of other eips that are more forward looking after Fussaka. So let's dive in and to kick us off with Petra. First, st yeah. Anyone have any updates on Hoodie. I think an obvious one will be the attestation analysis that clients have been doing. Would anyone like to say anything about Hoodie.

Parithosh Jayanthi: Yeah, I can go. But maybe Philip can follow up shortly. So we've done one round of testing, and I think I'll let Philip mention what the tests are and the outcome. But one thing I do want to mention on the attestation topic is, sam has a post 2 posts on Eth. R. And D, and the interrupt chat interrupt chat. I think the unexplained pit is probably very small at this moment. It looks like most of the attestation loss, at least according to what we're seeing, is struggling validators on infra and nimbus, producing some blocks that have inclusion distance. One. yeah. And mainly wanna discuss that after the updates to see if client teams are seeing the same or not.

Alex Stokes: Okay, you mentioned, Philip might have another update that.

pk910: Just joined. Sorry? yeah, we've noticed a small thing. We've done a lot of top up deficits on Heleshki. and we have expected that to clear up in about 2 weeks, but it turned out it will take much longer, because there is another restriction that limits the number of processed deposit requests per epoch to 16, and that basically leads to a reduced amount of eth that enter that is, entering the related set to a maximum of 16 eth. Per epoch. If you have a lot of top up deposits. So yeah, that's the question. If that's it. This is intended, or yeah.

Alex Stokes: Yeah, I mean, the short answer is, yes. That mechanism is there for cost resistance? I don't think we really intended to, or at least we don't expect a lot of the top ups on Mainnet. So from there. Yeah. And if anyone else has anything else to add.

Ben Adams: Stop across.

pk910: The problem is clearing up the queue. The queue will take quite long. And the it is a possible attack vector to mainnet as well, because it doesn't cost any. If you get back the Eth after withdrawal again. So.

Ben Adams: Russians seem to be suffering from.

Alex Stokes: The I don't know if Mikhail's here. I know that he was looking at this but I don't see him. So. Yeah, I mean, we discussed this some last year interrupt. And this was the mechanism we settled on. The question really is, how much do we think people will go their way to group this this mechanism. Cause. Really, it would just be, you know, a bunch of top ups. And I think at the time we decided the risk was pretty low. Okay, barn was the same. We did a bunch on Helloski.

Any client teams want to add anything to this point. Correct. Follow up. I'll follow up. I'll follow up offline on this getting back to the attestation point I would like to hear from client teams what they're seeing. I know that. Yeah, there's been some discussion here around attestation performance and packing into blocks. And yeah, Perry mentioned what he was seeing. Can other clients corroborate.

Terence Tsao: So for prism, we'll we change our attestation packing policy from highest slot to simulate. Based on reward numerator, basically how we process attestations. It's a state transition function. So we basically run that thanks to lighthouse and many for the inspiration. So we we merged the change last week, and we did like a few days of testing on who? The just pre just basically pretending we're a proposer, every slot. So packing attestations as they come into the main pool. So I sure heck and the the discord earlier the week, basically just to see, like how we are packing those associations. So for slot 0, it's basically almost perfect. So the perfect committee in this is, I guess, before they actually mentioned how we aggregate attestations. So I, every client does this slightly differently so, for we we update them. So we listen to all the single attestations, and then we aggregate them on demand.

And then we listen to aggregated attestations. And we basically does this greedy just keep aggregating them. And at the end we typically have about like 40 attestations to choose from. Those are like the final product. And we just sort them by reward. And yeah, so slots. So index 0 is typically the best attestations. Like everything is perfect. The aggregated you get 16 committee beats, and then 27,000 aggregation beats. and that's the one with the highest numerator. But then, as he goes down that we started, including more like, I would say, overlapping attestations. Basically, those attestations still have attesters that haven't attested, but most of the attestation bits are already attested. So you start seeing more of those you see attestations from older slots and stuff like that. So I don't. I mean, I don't really have much of a takeaway, I think, like

I think 8 at stations per block is more than enough because of like, I can see from the last 4. Typically just, I would say, more or less slightly weak, very weak at stations. Yeah. So that's my basically my learning from the experiment. I think what we have is fine. But it would be good to have more client teams, input, because this is independent of present implementation and other client implementation may do this differently.

Enrico Del Fante: So we are experimenting in Teku right now. We have a couple of approaches that we want to to run. So essentially, we have a similar approach to yours. So we have an updated version, and it we pretend to run every every slot. the block packing process, the attestation packing process. And we want to do some comparison. So we will produce some metrics around that. So the current strategy we are thinking of. So this, this thing is now parameterized, based on different things. But the overall strategy is to essentially, pack. First, st all the aggregations that we receive. We also store single attestation independently, not not agreeing them.

And so the so it the the strategy, is actually divided into steps. The 1st one is aggregating all the aggregation, sort them by by rewards. Then we select the the 1st 8 that we get. and then we start the process that we call fill up using the single attestation that we have in the pool, if any, and we try to improve what we have. And this is time box. So we could have a lot of single attestation in the pool, and if we want to go through all of them we could easily go out of time. So we we have a time limit there and can be configurable. And then we are playing with these values.

So we have a baseline of aggregating aggregations, which is pretty fast in the order of 100 ms normally. and then we take the rest of the time a little bit to improve at improve that and and deliver the packing. We. We will run these experiments during these days and and crunch some data. Maybe we'll share.

Alex Stokes: Okay, thanks. Anyone else. Have anything to add or want to share your strategy.

Parithosh Jayanthi: And just one closing point on Hoodie. We've since last week already done the Consolidation request, etc, and those were in the queue. So just wanna give an update that they've all been processed. The balance has been transferred as expected. There's been like a bunch of other attempts to try and break the consolidation mechanism. And it seems like everything's working as expected. They've also been partial withdrawals performed top ups and a few other Maxib related activities, and Hoodie seems to be fine so far.

Alex Stokes: Okay, that's great to hear. So with the consolidations in, does that round out all the different execution, request types.

Parithosh Jayanthi: Yeah, that should be. Yes.

Alex Stokes: Yeah, cool. Thank you. Okay. so yeah, I mean, I think the main point we're getting at here is mean that timing for Petra. I did want to call out Heleshke, because I guess that was another sort of basket of things that we had on the plate. There are a series of non finality scenarios we wanted to test. And yeah, I'm not sure anyone has much to add at this point in terms of that topic exactly. But let's just keep it in mind as we move forward. And otherwise. Yeah, I think we can then just go ahead and turn to the topic. So last week on Acde there's a proposal for an April 30th mainnet date.

I think since then there was some Async Comms around the State, maybe being a little aggressive given the attestation analysis we were just talking about. Given the things we saw on Heleski, and to some extent sepulia with Petra? Yeah. A number of.

Lion Dapplion: I'm sorry.

Alex Stokes: I think. Let me mute that plan. And yeah, a number of other bugs that have come up over the last few weeks. So keeping that all in mind I would like to either go ahead and confirm the April 30th date on this call, or suggest a different one, and then we could go back to next week's acde and hopefully finalize that one there. So how is everyone feeling? Are we comfortable with this April 30th date, or do we want to push forward some amount of time? Okay, there's some chat comments. Dustin says, yeah. Some bugs that came up. There's a 30 days.

Yeah. So this was another point that came up essentially, having 30 days from the Confirmation date to the fork. And I believe, okay, so we did have some numbers here, let me pull up the table from A B khatoop. I'll drop this in the chat. Okay, thanks, Tim. So right? So that we had the April 30th day last week we could push forward one week to May 7th 2 weeks to May 14, th and we can kind of keep going from there. So okay, Teku, preference for mid-may. And okay, thanks. Enrico. Oh, yeah, Shawn.

Sean Anderson: Yeah, for lighthouse. We we agreed as a team that we could do may 7th so, or later. Obviously.

Alex Stokes: Okay. So then, what do you think about May 7, th if I'm reading the chart correctly here, I think May 7th would say, would give us even more than 30 days from today. Okay, getting some consensus around May 7th in the chat. Anyone opposed to May 7.th Otherwise we'll lock it in. Yeah, Tommy.

Tim Beiko: Okay. So I assume, if the El Teams last week were okay with April 30, th then May 7 should be fine for everyone, as we can pick that as a given unless someone brings up an objection. But at least 2 of the El teams have confirmed. I may set it in the chat. If we are gonna do this, then I think, yeah, like we discussed last week, we should ask client teams put out releases Flag, who on the client team will be kind of monitoring the release and then we should also figure out when we want the actual client releases to go out. How much time we want to get people to update? yes, because

I I don't know if these comments I I assume these comments about the 30 days are not from having the releases out, but we still want a couple of weeks. So if we do, may 7th which is a Wednesday, our teams comfortable, having their releases out by, say, like April 21st or so. Such that we can put out the announcement like a proper 2 weeks in advance? Or do people feel we need even more time than that? I think 2 weeks. It's probably reasonable. If yeah, if we have all the client teams releases.

Alex Stokes: Yeah. 2 weeks sounds good on the release cycle.

Tim Beiko: Okay? So then, this means like, yeah, if and it is gonna be Easter weekend. So it might affect some of the teams and their release cycles. But ideally, all the teams releases are out by April 20, second and then we can put the announcement that they are at the very latest. On April 23.rd

Alex Stokes: Okay, let's do it. So yeah, the confirmed date. So yeah, we'll go ahead and lock in May 7th for Petra on Mayna. Seems everyone's okay with that. And yeah, happy, Petra, everyone. In the meantime, yeah, I mean, clients will be busy, I guess, with these other issues that we mentioned. That gives a few more weeks to do some further analysis. yeah, and then otherwise, I believe, Tim said, April 21st would be releases. and then 2 weeks later, will be the 7.th We'll have the fork. Okay.

Gary Schulte: Hmm! Anything else on.

Alex Stokes: Extra.

Gary Schulte: I thought I need another coffee.

Alex Stokes: Okay, if there's nothing else on Petra for now. then, we'll turn to pure dos. And yeah, there wasn't too much to say here. I think everyone's pretty busy just implementing the current specs for Devnet 6, and fixing things with Devnet 5, are there any devnet? 5 updates worth mentioning? Okay, yeah. I think if you want more detail here, there is a breakout this week that I'd recommend checking out the recording of essentially, our clients are just moving forward with different bugs as they come up there and then. Yeah, moving towards Devnet 6. So Perry here linked the specs in the chat. Thank you for that. And yeah, that's pretty much the latest there. Okay, next up. Then I did want to at least call this out.

So one thing that we'll want to do is with pure dos. Right? So we have the option to think about scaling the blobs with Petra will be a 6, 9. Then the question is, how much higher do we want to go in Fussaka? So you know, one way we can imagine doing this is looking at the period of design. It gives us a theoretical 8 x over wherever we would be today. And so you know from then that goes from 6, 9 to 8 times that we could imagine just kind of rolling that out right. If it's right at the physical fork. you can imagine a more conservative strategy is to do this more gradually, and that's where this idea of a blog parameter only fork has come in a vpo fork

sort of to date with Vpo. It's just been more of the structure of the idea without actual parameters. So I put together this documents here that I put in the chat that suggest an actual schedule. So the schedule in the dock is the following, we would have Fusaka. We would wait 2 weeks to have an observation period. And this is essentially Fusaka with the extra bob parameter counts. So let's say, Fusaka at 6, 9, 2 weeks, just to see that the new pure dos. Mechanism is working on Mainnets. There aren't any surprises. Then from there you move to a series of automated increases where every 2 months you would double the blob. Count up until the theoretical maximum that we expect

you would implement this with this Bpo eip that each dreamer suggested. Let me grab the number. It was 7, 8, 9, 2. And the way this works is that you'd essentially have configuration. That says, Okay, at this epoch the law parameters target Max, and then also the the feed divisor would be this. add this next epoch. The blog parameters would be this, and then you just implement the increases this way. So I think this is like a pretty straightforward and simple way to handle these increases. You could imagine a more, you know, gradual mechanism, where, rather than like a doubling every 2 months, you have, you know, something even sort of on the other end of the spectrum could be, you know some bob increase every week.

There's parameters here, and we can play with them, I think ultimately they'll be informed by further analysis on pure dos devnets, and as we get closer to Mainnets we'll just have a better clue of what we think works so either way, that was kind of a long spiel. Does anyone have any questions for what I just said, or any comments on this? We don't need to decide the exact schedule today. But I did want to get it on everyone's radar just because we should decide soon. at least start moving towards something that we all like. Yeah, answer.

Ansgar Dietrichs: Yeah, just a quick one on my side would be that I like the strategy. The one caution that I would have is that we should never pre commit programmatically to an increase to level that is not yet stable at the time we make that pre commitment. So even if we're like, okay, it's a very slow rollout. We have 3 step ups over the course of 6 months. And so at the end of that, those 3 steps. We are at a certain throughput level. If by the time we make that pre commitment we don't have that stable on devnets, yet I, personally, would feel very uncomfortable with that, because who knows whether we'll actually get to getting that stable within those 6 months? And then we are under pressure to do that. So I think

we should see, what can we get to stability? And then basically have a gradual rollout up to that level? And then, if we after that find ways to push further. Then that should be normal manual fox and not not pre-committed.

Alex Stokes: Yeah, that makes a lot of sense, Casey.

Kasey Kirkham: I wanted to suggest that we program in a rollback shortly after the 1st step up, just so that we can test if that mechanism works. I think there are reasons that rollbacks could cause problems like L twos could continue posting high index blobs. So I think. And it's just good to test a rollback rollback production to make sure it works when you need it. So like, let's program that into the schedule.

Alex Stokes: Yeah, that's a nice idea. And I didn't really touch on in the document that I posted. Because, yeah, I mean, what we don't want is. you know. Let's say we do this doubling every 2 months. You know, you can imagine that going from current level to 2 X to the next level something like breaks quite badly. And then it's like we need to fix it. Given the vip, 7, 8, 9, 2, it would essentially mean shipping this new config to the entire network in a very short period of time. So I think that's certainly a at least a concern with the strategy overall that we should think about more. Presumably we would vet these numbers like, Oscar was saying, before you know, we move forward with them.

That being said it would be quite hectic if we need to like, do this sort of emergency patch. So that's something we should all keep in mind. And it's probably worth calling out, then, that there are other ideas around how to handle this. So Vitalik had a comment on the agenda here. essentially having this be rather than have a programmatic schedule, you would actually just have this in the control of stakers. I think most people I've talked to prefer the programmatic option. I'm not sure if anyone would like to explore the other option or have any comments express support. You know, Tldr. This would look essentially like the gas limit. Today, there's just now a bob limit parameter that's under control of speakers.

The right? Yeah. So just looking in the comments here people seem to lean towards this programmatic approach a concern I would have with the validator controlled. Option is essentially just apathy where clients are not clients. Sorry. But validators aren't really paying attention. Or we have issues, you know, actually getting to the thresholds. We need to upgrade. Then we have no way to increase the blog count further. Okay, I guess one more comment here. Vitalik also suggested a different parameterization for the schedule. I think this is something we can keep talking about. There was here. I'll just grab a link here if people are interested. So it's this Github comment. I just put in the chat here, and it's just a different formula. I think this one's a little more gradual, and you know there's trade offs for doing something that's more, you know, stepwise versus something that's more gradual.

We have options here. We don't need to decide today, but something to be thinking about. So we can decide over the next few months, I would say. Okay, let's see, is Eve dreamer on the call.

Mark Mackey: Yep.

Alex Stokes: Oh, yeah, anything you'd like to add around, because I believe you wrote 7, 8, 9, 2 anything else to highlight? There.

Mark Mackey: I mean, I'll just say that it wasn't very difficult to implement from what I saw, I think on the execution side. Because we already had had that eip that I think it ends in 8 4 0. I can't remember the full number but that that puts all of these parameters inside the config that they're kind of co-located in the code. So, at least at least with Ref, that I tried was fairly easy on the on the consensus side. It was also fairly easy. I heard that nimbus might have trouble, but the only thing I ran into was that, like that, added any sort of complexity at all was just that we have rpc limit sizes for the blocks which before this are only a function of the fork in the fork version but with this change

there are potentially like a different number of Kcg proofs allowed in the block, if we but within the same fork, if that makes sense so like. At 1 point in the fork, there will be some number of Kcg. Proofs allowed, and at another point in the same fork a larger number of Kcg proofs will be allowed and that would change what the maximum size that a block can be. I don't think that's like a terrible thing, as you can just kind of set the Max. I think I don't know that it has to be exact, or you can and can write around it. But that was the only complexity I ran into. It was, it was fairly simple.

Dustin Brody: Okay. I guess I'd like to comment a bit on the nimbus thing. Nimbus certainly can implement this. It's not dramatically more complex to be clear. However, there is a case where Nimbus right now does not have. It's a much more. I just brought in broad terms type driven approach. Let's say, to implementing a bn, and so each of the forks is its own set of types. We do not have a single beacon state or beacon block type. We have one per fork what it and that that permeates the design, and that means that we have never had a need to have any specific function. Hitherto this this proposal to select a a particular limit. It sort of comes baked in because well, a certain beacon block type comes with a certain limit. And that said, I mean, it's not a terribly difficult software engineering exercise, but it would be kind of

yeah, it it. It would look a little alien in the code base. But it's fine. Yeah.

Alex Stokes: Okay, yeah. I mean, I think the main thing would just be changing. What's now? It sounds like a compile time parameter with the block counts to a dynamic one which you know. This may take a little refactoring, but I think everyone is pretty strongly in favor of this Bpo strategy. So that's what this implies.

Dustin Brody: Right. Oh, for for numbers it already is runtime. That that part is not. It's the way in which it's chosen. We, the way we know which runtime config to to use, though is purely a function of fork. And the thing is because we're already so driven by this again, this type system. We that sort of implicit in that and this wouldn't make an explicit. But but again, it's relatively it. It's a slightly different tweak of how it's done at Runtime. It is doable. Certainly, and that's fine. I guess I mean my my broader concerns are sort of other things not so much this the specific software engineering. But I think that's definitely feasible. I mean there, which have been discussed and already about well, you know the

Do you try to upgrade everyone with short notice, or run into pre commitments, or all, all of that things set of things? But.

Alex Stokes: Yeah, that's okay. That makes sense. And yeah, I do expect we will discuss this more on future calls to get to the exact strategy that we like. But yeah, I did want to start steering us towards thinking about the stuff so that we can get there eventually.

Trent Van Epps: Hey, Alex? Just to surface it. There's some discussion that maybe we can go back to for release.

Alex Stokes: I was just about to circle back to that. Would you like to say something, Trent, or.

Trent Van Epps: No no just.

Alex Stokes: Can. I can jump in.

Trent Van Epps: Yeah. Go ahead.

Alex Stokes: Thank you. Yeah, yeah. There's a lot of stuff in the chat. Thanks for flagging it. So yeah, I think there was some discussion here around the release date versus the main net date. So main net would be main set. May 7.th And then the question is, do we want 2 or 3 weeks. Dopp Lion, I think you might have raised the original question. Did you have a concern with that.

Lion Dapplion: No, I'm just mentioning. If we have decided for 2 or 3 weeks, I think 3 weeks is still quite but ahead. But we can go for 3, and then if some client needs more testing, they can delay the 2 weeks. I'm not sure if I think everyone else feels ready. so we can target 3 and then do 2. If we need extra time.

Alex Stokes: Most to give you more time. But the 2 weeks here is just for the release cycle. Right? So like, you have releases out, okay, yeah. 10.

Tim Beiko: Yeah, I was gonna say, so 3 weeks you're saying releases are out by April 14, th which is which is like 10 days from now. I don't have a strong opinion either way. But yeah, my perception was that teams wanted more time to work on the code. Historically, we've the last 2 forks we've given just over 2 weeks. yeah. So I, yeah, if if people feel like we want to give the community 3 weeks, that's good. If people prefer to have like a blog post that doesn't list all the clients. That's also an option. But my sense is historically, people really hate that idea, and we've only done it in like some pretty unusual cases or and

and and often it's like, maybe a couple of days of lag. But yeah, we should make this decision now. and I guess one thing to note as well is, if we agree to the 4th block today, we can communicate that to the community, and they can know that there'll be a blog post in 2 weeks, and that they'll then have, or there'll be a blog post in maybe 3 weeks from now, or whatever, and then they'll have 2 weeks from that point on to update their client. My sense is, that's like a reasonable amount of time for pretty much everyone to upgrade. But I don't know.

Alex Stokes: Yeah, usually, we've done 2 weeks between releases and fork and to your point. And I think to others points. It gives clients more time to look at the code before having to ship a release. So 2 weeks well releases in 3 weeks, and then 2 weeks, until of work makes more sense to me than the other way around.

Tim Beiko: But I think we can be. We can be better at communicating to the ecosystem that you know this is the fork date, and this is when the client releases will be out, so that you know, if you're working on like in some like complex system, and you need to update your nodes, or if you're like a solo sticker, whatever, you can already put something on your calendar that within those 2 weeks you'll have to upgrade. Then you can expect your clients to be out. I'm does that seem reasonable?

Alex Stokes: The Comms seems reasonable. And then I would suggest just to give 2 weeks in between releases. I mean that. But it sounds like maybe we were asking for more time in between those.

Enrico Del Fante: So in my perspective, at least, we we could even give 3 weeks and release earlier, because at the end, what we have now is still okay. We are just working on improvement on on attestation pool that can anyway be shipped a little bit later. And we can definitely provide an early, an early version with what we have now, that is fully spectra compatible, and then may release something in between that is, contains some some improvements that can be. I do think.

Tim Beiko: So I think it's fine for take you to do that. Then obviously every client team can talk to their users. You don't need to go through the ef blog to do this. But I would prefer not to have too much thrash on the actual blog post release. So like when people look at the blog post, it would be nice for those releases to not change in the past. yeah, in in the past we have changed them. But it's basically been like when there's a bug found or something like that. So for example, in this case, if like, take who has a release out like today. That's that works in some early version. Then. Great, you can advertise that. But I would.

I would prefer that we have a blog post with the final releases.

Enrico Del Fante: Yeah, yeah, I'm talking about a world in which we release something that is newer. But we don't change the blog post. Because, anyway, what is in there is fine.

Tim Beiko: Yeah, yeah, yeah. Yeah. I think that makes sense.

Alex Stokes: So yeah, to your point, Tim. Here in the chat and Terrence's points like we can have the later date for the blog. And sure, if people want to release earlier, that's fine. Okay? I mean, Barnabas is suggesting a more aggressive schedule. I mean the whole point. We are going to change from your last week's date was to give clients more time, so I don't see why we wouldn't just take the time. Barnabas, how strongly do you want the 16th day. or do you have a reason for doing so?

Barnabas Busa: It's more like for just testing the stable releases. So having one extra week to Thursday minute releases, I think it possibly could be better.

Alex Stokes: I see. So yeah, would some sort of rolling strategy help there where it's like, in terms of what the community sees. We have one more week, so releases must be ready by, say, the 21st at the latest blog post that day, or in the next couple of days. That gives 2 weeks until Mainnet. And sure, if people are ready, they can release earlier. And any testing we want to do on those releases can be done at that time.

Parithosh Jayanthi: Yeah, I think we also don't have to wait for every client to release to do testing. The moment it releases out, we can already start doing some.

Alex Stokes: Yeah, yeah, that's what I meant by the the rolling word, if that wasn't clear. Okay, so are we comfortable with that schedule? So May 7th may net 2 weeks prior, let's say, is the blog post. It might go out a day or 2 earlier than that which means releases are done by then. So let's say the 21.st If your release is ready earlier, that would help testing. So if you're ready, don't be shy. Okay. There's no disagreements. Are we happy with the schedule now?

Otherwise, we're gonna ship it. So this is your last chance. Okay, thank you. Okay, so extra. Here it is next up. We have Fusaka and okay, a number of well, let me say this first.st So. Posaka, we had a deadline. What was it? March? I think it might have been Monday or last week, I forget. But either way there is a Pfi deadline that has passed. Now the question is, what do we actually want to include in Fusaka Market Sfi, which is scheduled schedule for inclusion? There's a number of eips that have been pfi'd so far. There's quite a long list

from there. Only a small subset are Cl. Things. and at the same time clients have put out their preferences. There's a number of them listed here on the agenda if you want to take a look. And yeah, I guess the Tldr is that uniformly people want pure dos. And Bpo, which is 7, 8, 9, 2. There are a few smaller things from there that clients either were considering, or that would be helpful. I think, from here. Let's hear from clients. If there are other things they'd like to include in Fusaka. So I think we can agree, for now pure dos and the Bpo, eip. Anything else anyone would like to propose. and maybe to frame this a bit ideally, we can get to like a final cl.

as if I said. Today I can take that to Acd next week, and then we can wrap up the Fussaka Fork, which was the intent to have that done by April 10, th which is the next week's call. So yeah, let's start there and hear from clients. There are another. There are a few other Cl pfi Ips, that clients did not mention that we can touch on after that. Yeah. Sounds good asking if this is just the seal side correct. And with regards to Uf, we decided last week that was going in. Yeah, Mark.

Mark Mackey: Yeah. So I would like to advocate for the proposure. Look ahead, eip, believe that's 7, 9, 1 7 So in after Petra. We've dramatically changed the the number of times that the effective balances can change in an epoch because they can change anytime. There's a consolidation or a deposit to top up a validator or a withdrawal of more than one eth. Or just when compounding validators balances cross an integer number of Eth. So this makes the the proposer look ahead more unstable, which is difficult for pre-conf protocols to deal with. Now we've had some discussion about just how much more. This changes things.

And we have found that it's it's actually kind of rare to change. Say, like the 1st slot in the the epoch. I ran a simulation of like 50,000 epochs, and didn't see it happen once, but of that 50,000 epochs 217,000 times an effective balance was changed between one epoch and another. So it it. The effect of balances. Changes definitely happen more frequently. This vip basically just takes like slaps an array into the beacon state and pre-calculates like during epoch processing, it pre-calculates all the composers for an epoch, and just appends them to the array. and it just reads from the array when closer to make it more stable. I did implement this in lighthouse. It

really only took me a couple hours, and it would have been faster. But there's been a bunch of changes in Lighthouse. So I posted the diff in chat so that you can see just how small it is. Even if the actual changing of the 1st proposer in the epoch is rare. It's still quite a problem for pre-comp protocols because they need to get the proposers for the next epoch on chain. And it's your classic crypto spectrum where you know you have a couple of options. You can prove things you can use crypto economics, or you can trust oracles. The problem is that they can't really use crypto economics. Because Well, I mean, if occasionally the proposals end up being unstable, and you're relying on some one of the validators to put up what the the

the proposers are in the next epoch, but that might occasionally change. You're gonna end up slashing someone who is participating honestly. So it kind of seems that their only viable options are to either have a proof or to use oracles, and the only way they can have a proof is, if we have the cip where the proposers are actually on chain, and then they can use the access to the this Beacon State roots to prove who the proposers are. And so I think that's probably the strongest argument for the cip is that these Protocols will be able to have a proof of who the proposers are, and then follow the rules of their protocol to know who their pre-comfer is.

Yeah. So I'll just basically say, it's a very quick eip to implement it's not a huge change, and I think it's worth it for pre-comp protocols.

Alex Stokes: Alright. Thanks. Yeah, Lynn, I know that you we're working on this. Do you have anything that you'd like to add.

Lin Oshitani: Yeah. And I think that like, whereas it will like. yeah, just to reiterate like, even if it is rare and like the upline. Did a really good analysis on how rare this is. And yeah, marketed some like relations. And for all that. But yeah, even if it is rare, like just the fact that it is possible like complicates a pre confirmation protocol like it is because even if it is an edge case, it is an edge case to consider. And yeah, and also like, just having the visibility of the look ahead in the Evm, it's like greatly simplifies the pre confirmation protocols that we're building. So yes, it'll be very nice if we can get this in.

Alex Stokes: Ahmad, you had your hand up. I don't know if that was.

Ahmad Bitar: Yeah, I was. Gonna yeah, I was just gonna say that. So currently, the pre so to elaborate on what Lynn said, currently the pre-confirmation protocols have to do an optimistic kind of look ahead mechanism where someone posts the look ahead. And and then. after the fact that a proposer proposes a block that we check using the beacon block route of the previous block. If the proposer is actually the correct proposer in the look ahead that was posted, and if they're not, then that look ahead. Poster is slashed, which is a crypto. Economic mechanism to this. having the look ahead being part of the State allows us to easily use the beacon block route to prove the validity of the look ahead beforehand and removes this requirement for

optimistic and crypto economic slashing for the look ahead. Mechanism. I yeah, just wanted to clarify. Why, that's very useful.

Alex Stokes: Thanks. You know, top line.

Lion Dapplion: Yeah. After doing the analysis, I convinced myself that this is rare, but I had chat with Lee, and I think the the true argument for this feature is, as far as I understand, there's no way. even with hacks, to to prove if some pre-conf has actually submitted the wrong look ahead, or there has been this fumble in the protocol. Therefore this would deter adoption of the feature. and that directly affects the intention to move to becomes. So I I see, and I agree that precomps are really important for the protocol to have based on native roll ups that are at parity with more scalable. l. 1 s. And centralized sequencers. Therefore this materially advances the roadmap.

There's the question of adoption. If this technology will be adopted within the next year or within the next 2, but at least, judging from the platform, like the sequencer calls, seems that this thing is quite down into the pipeline. So, after my analysis, I I would. I'm in favor of adopting this, and I think Mark has shown that it's not a very complicated change unless we are missing something so to reiterate as long as there is no other hack to achieve the same level of assurances. For duplicate, that they will not have this negative lottery, of sometimes getting slashed. For no reason we should adopt something like this. And then for the topic of privacy.

Yes, this feature would, I think, neglect the possibility of doing Ssle as it's currently specced. But the feature that is currently spec it's quite complicated. And I don't foresee adoption of it due to the how expensive it is in terms of state bloat and competition overhead. And I don't know. I'm I'm hopeful that we can find a way in the in the future to to do it if we need to. But the reality is precoms have to happen, and then we need to find another mechanism to ensure safety. So yeah, I wouldn't. I wouldn't personally block this feature with for essentially.

Alex Stokes: Okay, any other questions or comments there.

Lin Oshitani: And one last comment I would make is that, like this whole thing, the fact that the effect balance during the epoch can change the next epoch. Look ahead like I think it's also in general, like, even without reconfirming. It's very huge for pre confirmation, but even without reconfirmations, I think it's like a pinpoint in general in terms of of a protocol. It makes a security analysis harder, because, like the effective balance change can affect potentially and potentially in a ways in a malicious way, like, we haven't found a new text, but is a possibility to consider. And also, yeah, just, it's just that even in the cl clients. It's like an edge case where you always have to consider.

And I think it just makes sense to. Yep. Yeah, Justin.

Justin Drake: I just wanted to zoom out and provide the kind of the bigger picture perspective. From my view, we're trying to do 2 things from a performance standpoint, we're trying to increase throughput and reduce latency. And on the increasing throughput side of things. You know, we have this whole massive roadmap around Das, and and that's that's something that will pay dividends. In the case of improving latency. My hope was that we didn't need any hard fork. Turns out I was wrong, but we do need a small one, and my hope is that the size of the fork relative to the outsized benefits that we could get if we were to significantly reduce the Ux latency. And it makes

makes this proposition like very attractive to me. Now, one thing that was mentioned is around. You know, the the timelines for adoption. Adoption can only happen after we've we've actually shipped it and and built it. And I think, having this change will significantly shorten the the timelines for for shipping it, and therefore hopefully shorten the timelines for for adoption, as well.

Alex Stokes: Thank you. Okay. So I would say, Let's just keep this to the side. There were a few other pfi vips to call out one that is not on this list is fossil, but from talking with clients. It seems like there's pretty unanimous consensus that we would save that for a future fork. Otherwise there were 2 others along with 7, 9, 1, 7 that we just discussed, and another here that we would like to touch on is 7, 9, 1, 8, Anders. This was you. Would you like to give us an overview.

Anders Elowsson: Oh, yeah, I can give a short pitch. Do you hear me?

Alex Stokes: Yep, I can hear you.

Anders Elowsson: Yeah, okay? So yeah. So I want to pitch it sort of from a scaling perspective. So the current blob fee market doesn't actually account, you know, for the real blob space demand function, because it doesn't account for the cost of the blob current transaction. And the consequence of this is that the fee update becomes insignificant when a Tx cost dominates, and the fee market then fails to converge on an equilibrium in a timely manner. So you end up in these situations where the base fee may increase by 10% per slot. Everything looks good, but the cost of blob space is just increased by 0 point 0 0 1% per slot trying to attain an equilibrium which, of course, is not happening

because the Tx cost dominates, and this eip resolves it by imposing at least fee parity between the cheapest bulk transaction and the total fee for target number of blobs, and this stops the blob base fee from falling into the region where the Tx cost dominates, and it acts similar to Eip, 7,762, but will adapt with the execution, base fee and future scaling. So I'm pitching it from a scaling perspective. This aap is sort of offered better guarantees that we will not exceed target bloops for very long, because the price adjustment, when demand exceeds supplies, will always have an effect on demand. In this regard. It enables to raise through, but more than what we otherwise might be comfortable with.

and it's achieved by adding an if statement to the calc excess blob gas function. So it says, if the Ts cost dominates, do not subtract target blob gas, so you increase the excess blob gas moderately, otherwise proceed as normal. Yeah.

Alex Stokes: Okay, thanks. okay, yeah. Thanks for the overview. And yeah, on square does have a good point that this is probably mostly on the El side.

Anders Elowsson: Yeah, yeah, exactly. Yeah, yeah, definitely.

Alex Stokes: Okay. Gotcha.

Anders Elowsson: But it's sort of a scale from a scaling perspective if you want to scale. So.

Alex Stokes: Right? Okay? yeah. I would suggest taking this to next week's call. There will be another round of this Cfi conversation next week. So, yeah, but yeah, thanks for sharing today. Okay, good gender. You wanted to bring up 7, 8, 9, 8.

Gajinder Singh: Yep, thanks, Alex. And so the idea behind 7, 8, 9, 8 is quite simple, basically in the big in the jumbo big blocks devnet. Basically, the issues that we saw cl clients are facing were basically because of the payload being big. And the cip just proposes that the payloads can be uncoupled from the beacon block and can be independently transmitted, and instead of execution payload, we'll now have execution payload header in the Beacon block which will make all the payloads as such blinded and and the availability model will also not change in the sense that we cannot, will wait like how they wait for blobs for payload to become available before they import import the block and over time basically when when we go to go to Zkra. These payloads themselves can be treated like block like blobs, because then you don't execute actually need to execute these transactions, and you would be able to verify the validity of them through Zk proofs so basically, this helps in in basically

batching or parallelly transmitting execution pay execution payloads, and as well as saving the cl clients from utilization of of huge number of transactions. So the these are the benefits. And I think it is a pretty simple change in terms of concept as well as execution. Yeah.

Mark Mackey: A, I don't think implementation. It's a simple change like decoupling. These 2 is most of the work of implementing. Yeah. P. 7, 7, 3, 2, and, like you have to implement a whole. Another block processing.

Gajinder Singh: 7, 7, 3, 2 is more complex because you have the availability models also changing over there. And so basically, nothing else is changing right now. So there is no Fok choice rules that are getting changed and updated. You just wait for execution. Payload to be available like for blobs to be available.

Mark Mackey: Even I didn't even get to the stage of implementing the 4 choice rules I was just implementing, separating the 2 in 7, 7, 3, 2, and that took a long time. There's a whole separate block processing that has to be implemented.

Alex Stokes: I guess.

Potuz: Yeah, I want to clarify for Mark. I think the proposal is actually, it's actually simple. It's not the separation. It's not the separation that is useful in 7,732. The separation that is proposed here it's only for broadcasting. You would still need to verify the whole thing, even execution and everything, before attesting, and you need to get the whole block before doing anything. So this is only about broadcasting. for which I believe we have much better mechanisms. Any coding, any racial coding, would work better for broadcasting. We have been researching on random linear network coding, but also reed-solomon encoding what we already do, for blobs would be a better solution if it's only broadcasting.

Gajinder Singh: As well as saving the clients from the utilization load that would come with the huge number of transactions when we actually pump the gas. So that is the second benefit.

Alex Stokes: You're there. Thank you. And okay, I think there is one more thing to touch on, maybe a few more things, but the next one here, then, would be Eip. 7, 6, 8, 8. This was the forward compatible Ss structures. We touched on it last Acdc. At least, so I don't know if we need to have spend too much time here. but I will just call it out. It was Cfi, or sorry it was, pfi, and yeah, so it's on on the table. Anyone want to say anything briefly about this eip? Okay? And okay, there's 1 more thing to touch on, and then I'd like to just kind of then circle back and try to get to a proposal for

Fusaka Sfi out of everything we've just covered. But before that one thing Terrence brought up was Nplex. Terence, would you like to say anything about that? I think essentially the ask was to have a forcing function that in Fussaka we formally deprecate nplex and move to Yamex, or whatever else that's not inplex.

Terence Tsao: Yeah, basically, what you said, this has been in the consensus spec for phase 0 for a while as well.

Alex Stokes: Okay, cool. So in terms of Sfr. we have, I think, unanimous consent around pure dos and Bpo as a strategy to bump up the blobs everyone. Okay, Otis, would you like to then say something about 7, 7, 3, 2. I. My sense for clients was that they wanted to defer that until next work already.

Potuz: Well, so we officially mentioned something about timelines. If the timeline is still maintained, and we actually do commit to shipping peer does this year. By the end of Q. 3 start of Q. 4. I agree, and I won't have any complaints.

Alex Stokes: Okay, yeah, I think that's what everyone intends to do. So that was my framing here is that we assume that we go with pure dos ship pure dos as quickly as possible. Ideally, by the end of the year mark.

Mark Mackey: Yeah, I just wanted to say for the Bpo eip, like. I think the main thing I was trying to propose in the eap is that the schedule is specified in the config, and there is like a specific, a way of specifying that's specced in the eip. But, like, if anybody has better ideas like I'm all ears. I was just. It's just the 1st thing that came to my mind so open to suggestions on changing how the config should be specified.

Alex Stokes: Okay, yeah. And I think those sort of details at that level are still open for discussion. I would like today just to agree on that strategy. And yeah, I think the configuration approach you gave makes a lot of sense. Okay. So back then, to an Sfi set, we would have Puertos, Bpo, eip. And yeah, I guess, what else are there any other eips that we discussed today that we want to go ahead and include in that set it did seem like there is quite a bit of support for 7, 9, 1 7, which was the proposal. Look at the IP. So I think like the main trade off here will just be how much we focus on just pure dos versus including other things.

Potuz: I think the support of this was essentially lighthouse, plus a couple of researchers right.

Mark Mackey: In terms of people that voiced in this call so far. Yes, I mean.

Potuz: I assume, pre-confert as well.

Mark Mackey: Yeah. And Teku, this blog post said something like that. Their main consideration and other eaps is just disruptive. The changes and that they're open to eips that don't delay the fork, so I'd assume there are. But yeah, anyway, they seem compatible.

Alex Stokes: Okay. This one went to argue against inclusion.

Potuz: I would. This eip was like not finished reviewing and writing in less than like, not longer than 2 weeks ago. We're making a decision like this for the next fork. Now, this. Yeah, this is just out of what we typically do.

Alex Stokes: Okay, yeah, Tim, could you say more about Cfi versus Sfi.

Tim Beiko: Yeah. So I agree, we like. we want to avoid the mistakes that we've made in Petra of including a bunch of stuff. And only then realizing issues with it. So I think whatever we decide today, we should. And and this is also true. I would say the El side. We should only Sf. Cfi, and then keep working on pure das and eof get those stable, and then kind of selectively bring things in. And so maybe like, I don't kind of reframing this deadline. I was like, Okay, now we have, like a short list of like Cfi stuff, everything else we stop considering. But then we don't decide to just shove everything into into the next devnet, because we should make sure. Like, yeah, we we should make sure that we actually understand what we're doing.

like. And I think you know, the best example we have of this in in spectra is just like 7, 5, 4 9, like, I think we greatly underestimated the complexity, and it would have been much better to like. Have a bunch of other eips done. Then add this one, then realize what's wrong with this one. Then make a call about whether or not we want to keep it. Then try to shove it alongside a bunch of so yeah, that proposal is like we don't we? We sort of finalize our Cfi list and we don't sfi anything until we're ready to put on the next devnet, and then we can look at everything that we have. Cfi. No new proposals, and you know iteratively increase the definite size.

Alex Stokes: Okay, yeah, I think I was getting ahead of myself and missing the Cfi stuff. So I agree with the approach you laid out. I also agree that yeah, the cip is pretty new and some more time to let it bake would be good. So and for today, let's just focus on Cfi although I do think pure dos is already ssified. Correct.

Tim Beiko: Yeah, period after. Eof. So like, you know, we've agreed we're implementing those we should. We will ship them. But we should minimize the amount of things we bring in until we're ready to do so.

Alex Stokes: Okay? So then, in terms of Cfi. Oh, sorry. Did you have a comment on this.

Saulius Grigaitis: Yes, so so why, while I agree that this is a really new feature, suggested that. But I think at the same time I think this is This feature is a good example of of features that we definitely should consider very seriously, as as at least now it looks relatively simple change. Of course, we don't know what is hiding behind it until there is a bigger development in multiple clients and some testing this on and so on, but so far it looks relatively simple, and at the same time it has a huge potential for users. And this is where where Miss often criticized with the new updates. So I think, I would just ask all the teams to to think about these points. And and yeah, maybe maybe this is a really a great candidate feature where we can have a you know, some kind of

example or reference for the future. Features where we seriously consider, even when it's late, we consider such features. So yeah, that's my point.

Alex Stokes: Alright. Thanks. So okay, then, we have peardos that's sified in terms of Cfi. Would you like to go ahead and make 7, 9, 1 7 cfi. That gives the 7, 9, 1, 7 champions more time to work on test analysis. It gives other participants time to consider the feature in more depth. And the idea then, just to reiterate is that you know this basically says we. Well, I guess it's in the name it's considered for inclusion. It has not been scheduled yet, and I do like the strategy Tim laid out where basically Sfide would be. What's on the devnets now? And given Petra and everything that brought it would make a lot of sense to have very hardened devnets. Given one set of Sfi things before moving to Sfi additional things.

So with that context, are we okay with moving 7, 9, 1, 7 to Cfi. okay, no one is disagreeing. So let's go ahead and do that. Otherwise, let's see. Okay, so then there is enders Eip that will be touched on next week. And what else did we have? We did bring up 7, 6, 8 8 I believe last time we kind of settled on the fact that this is nice. But we wanna focus more on pure dos for the time being. Yeah. anyone want to move? 7, 6, 8, 8, 2 cfi.

or do we just want to table that for now? Okay, right. Bpo, so I think I think, given the process right now, Bpo will make more sense to Cfi. for example, that again, gives us more time to think about these details of how exactly we want to have the scheduling these different parameters I was mentioning, and the details of the config that Mark brought up. Let's move Bpo to Cfi. Everyone. Okay with that. Okay, I'll assume. That's yes. Peer to us. Vpo, 7, 9, 1, 7. Okay. Anything else we should clarify today.

Okay. Great. Then, okay, we have a few minutes left, and there is one more eip because we love the Ips. Mike, you wanted to. Intro 7, 9, 2, 2, and I think just to be clear, I believe the intent was not to have this go into Fusaka. but more a new body of work that Mike wanted to introduce.

Mike Neuder: Yeah. I mean, if people are stoked to do it in Fusaka, then that'd be great. I I don't think that's too likely. yeah, I'll just take a take a few minutes to to pitch this idea. It's kind of a little bit of the normal set of things that that people talk about with the consensus layer, but I think it's pretty important which is the exit queue. So I guess, to give the really concise pitch for this eip. It's it's summarized in this picture here. So I guess the the Tldr is that currently the I guess, like, let's let's talk about today. Pre Petra, because, after Petra, there's some changes with with 7,251. But it doesn't change it materially. So today, basically, the way the churn happens. The rate limiting of the exit Q happens is that there's kind of a fixed number of exits that can be processed per epoch. And this is something that happens looking forward in time. So currently like with today's numbers, about a million validators that corresponds to about 16 validators that can exit per epoch.

And the the point of this rate limiting is to ensure that basically the once a transaction gets finalized, the economic security of that finalization guarantee doesn't decrease by too much right, because the issue would be if if everyone could withdraw their stake immediately, the finality of that transaction wouldn't have the same economic weight behind it as if the stake was still in the consensus mechanism. So right the the way the rate limiting happens is kind of this per epoch thing. But what this ends up doing is kind of really constraining the flexibility of the queue. Because if you know, if there's a bunch of withdrawals that want to happen. Concurrently they have to get spread out and kind of

distributed over the many, many future epochs rather than processed immediately. So the the proposed change is that instead of looking forward in time to do the rate limit, you actually look backward in time. Because if you really think about it. What the what the queue needs to be. Rate limited on is basically within every like rolling window of time. We want to ensure that some amount of steak like can churn, and no more than that amount. And by looking backward in time, you can basically give the queue a lot more flexibility and say, Hey, like, if no exits were processed in the past 2 weeks, we can probably process more than 16 in the next epoch. Right? We. Maybe we feel like confident that we can can process.

you know, a thousand exits, because that doesn't change the economic security over the over the 2 week window. In in any meaningful way. So I guess that that's the pitch there's there's a lot to kind of read on this. I'll share the the specific Eth research post in the chat, and it has a link to both the the spec change. We wrote a paper. And there's also this validator exits. Eli. 5. Which kind of talks about how the changes are kind of gonna be implemented in Petra, like the there's a few slight differences you have to denominate the exits in terms of Eth instead of number of exits. But yeah, this is kind of the the high level, summary and happy to happy to take questions. Happy to talk about it. Offline or online. Yeah, thanks. Ox.

Oh, actually, I I do want to give Malash he's in the call a chance to to add anything. If if you'd like.

Mallesh: Hi, folks long time. Listener, 1st time caller. Yeah. So just I just wanted to answer sort of Danny's question in the chat Daniel. Sorry. We don't. we, we allow, sort of looking back. We allow more exits, but we don't necessarily allow it all the way. So if you're saying, okay, you can have, you know, 5% of stake exit in any 2 week period. We don't necessarily let 5% of stake leave in a single epoch. We just say, Okay, even if you've had no exits over the last 13 days, you can do a much higher rate. We propose 8 times the current rate, so you can speed it up a lot, but it still be smoothed out over the course of a day.

or something like that or 2 days, so that you don't have like massive instability in the valid data set, it's just a flexibility thing. So that if we kind of expect this to get bustier as we get staked etfs, and maybe more institutional stakers, and allowing more flexibility, is a good thing, reduces the rate, and so on.

Mike Neuder: Yeah, I guess it's worth mentioning here that the kind of one constraint that we seem to care about preserving is this weak subjectivity constraint which says, You know, I guess currently it's it's programmed to say something like over 30 days. No more than 10% of the stake can churn. And you know, if if that's the only number that we care about, then basically, that invariant is what we have to preserve over every 2 week period. And that's like something that that can be done by looking backwards in time and saying, Okay, 0% of the stake has churned in the past 2 weeks. So like we don't have to only do 16 per epoch. We can maybe process like much, much, much faster. Yeah. And as Malash was saying, like.

these withdraws might be kind of very bursty in the case of like market, like big market volatility. Events right like tariffs being announced, could could require a bunch of people to need to need to get out quickly. And yeah, the that type of stuff just making it more responsive seems like an an obvious win, and in terms of just making the the system more more flexible. I guess I also wanted to add 2 like 2 other super quick points, which is, there's 2 other, maybe, I guess one lower hanging fruit change to the exit. Queue that could be worth doing, which is all about this validator sweep. So currently, the the full withdrawal flow has these 3 phases. The validator sweep is just basically you. You iterate linearly through the whole validator set process, all the partial withdraws that are automatically done in line, and you do the full withdraws kind of

in the same set of in the same group. And as a result, basically, full withdraws have. like 4 or 5 days extra on average of wait time, just from the fact that all these partial withdraws have to get processed before the full withdrawal. This seems like kind of a no brainer to get rid of this sweep.

Mallesh: Yeah. And I'll just add to that that the existence of this sweep is leading to a lot of weird stuff that validators are doing on trying to make their validator indices uniformly separated across and sort of time which valid like, suppose I'm like coinbase or kill, or someone who controls a thousand plus validators. I sort of want my validator indices that are like markets coming up to trade validator indices or resell them like it's just unnecessary, or to my from my perspective respectfully, like stuff that's going off protocol to solve some like, you know, work around the hard constraint which is the sweep. Constraint adds, multiple days potentially.

Mike Neuder: Yep. And then the only other thing I wanted to say is, also pay for priority could be something we we implement. So currently, it's like just a fifo queue. You could turn it into a priority queue and allow people to to jump to the front of the line. There's kind of a lot to unpack there, so I don't think it's worth going into. But yeah, that's probably where I'll leave it.

Alex Stokes: Cool. Thank you very much. And these these second 2 things that you mentioned the uncoupling of like partial and full withdrawals, I think is what you're what you were getting at. And then also the sort of pay for priority with withdrawals. Those are separate from the cip that we just up here. Right? Okay.

Mike Neuder: Yeah, I think we'll probably propose an eip to to get rid of the sweep. That's I. I genuinely think that's the lowest hanging fruit and you know, just keeping them separate is is useful on, on, I guess. Specs spec level. But yeah, they could be combined into one eap to like, overhaul the the queue generally.

Alex Stokes: And you just mean, like different queues for full versus partial withdrawals.

Mike Neuder: Yeah, that's the simplest one, right?

Alex Stokes: Cool any other questions. If things come up Async, should they go to the E 3 search post? Or is there a better place.

Mike Neuder: Yeah. Eth, research post. You can. DM, me on twitter or telegram. We're super easy to get in touch with, so happy to chat.

Mallesh: Hey, Tom!

Alex Stokes: Cool. Thank you. Okay, we're basically at time. any closing comments. I think we got through everything today. And also, I think, made a lot of good progress towards Petra and Fusaka. Okay, then, thanks everyone. I'll see you next time.

Ansgar Dietrichs: Thank you. One thing.

Mikhail Kalinin: Thank you.

Mark Mackey: Thanks guys.

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