stokes:Okay, thank you.
Transcript
stokes:Hello, everyone.
stokes:This is Acdc, 1, 54.
stokes:It is issue 1399 in the Pm repo.
stokes:And yeah, we have a couple of things today.
stokes:We'll start with Petra, then turn to pure dos.
stokes:From there, go to essentially fausa inclusion. There are a number of other eips around pure dos that we can discuss.
stokes:and we'll wrap up at the end if there's time with a number of other eips that are more forward looking
stokes:after Fussaka. So let's dive in and to kick us off with Petra.
stokes:First, st yeah. Anyone have any updates on Hoodie.
stokes:I think an obvious one will be the attestation analysis that clients have been doing.
stokes:Would anyone like to say anything about Hoodie.
Parithosh Jayanthi:Yeah, I can go. But maybe Philip can follow up shortly.
Parithosh Jayanthi: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
Parithosh Jayanthi:Eth. R. And D, and the interrupt chat interrupt chat. I think the unexplained
Parithosh Jayanthi: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
Parithosh Jayanthi:and nimbus, producing some blocks that have inclusion distance. One.
Parithosh Jayanthi:yeah. And mainly wanna discuss that after the updates to see if client teams are seeing the same or not.
stokes:Okay, you mentioned, Philip might have another update that.
pk910:Just joined. Sorry?
pk910:yeah, we've noticed a small thing. We've done a lot of top up deficits on Heleshki.
pk910: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,
pk910:and that basically leads to a reduced
pk910: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.
pk910:So yeah, that's the question. If that's it. This is intended, or yeah.
stokes:Yeah, I mean, the short answer is, yes.
stokes: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.
stokes:So from there.
stokes:Yeah.
stokes: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
pk910:it is a possible attack
pk910: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.
stokes:The
stokes:I don't know if Mikhail's here. I know that he was looking at this
stokes:but I don't see him.
stokes:So. Yeah, I mean, we discussed this some last year interrupt. And
stokes:this was the mechanism we settled on.
stokes:The question really is, how much do we think people will go their way to group this this mechanism.
stokes:Cause. Really, it would just be, you know, a bunch of top ups.
stokes:And I think at the time we decided the risk was pretty low.
stokes:Okay, barn was the same. We did a bunch on Helloski.
stokes:Any client teams want to add anything to this point.
stokes:Correct.
stokes:Follow up. I'll follow up. I'll follow up offline on this
stokes:getting back to the attestation point
stokes: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.
stokes:And yeah, Perry mentioned what he was seeing.
stokes:Can other clients corroborate.
terence: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
terence: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
terence: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.
terence: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.
terence: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
terence: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
terence:I think 8
terence: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.
terence: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 (tbenr):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
Enrico Del Fante (tbenr):an updated version, and it we pretend to run every every slot.
Enrico Del Fante (tbenr):the block packing process, the attestation packing process. And we want to do some comparison. So we will produce some metrics
Enrico Del Fante (tbenr):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
Enrico Del Fante (tbenr):essentially, pack. First, st all the aggregations that we receive.
Enrico Del Fante (tbenr):We also store single attestation independently, not not agreeing them.
Enrico Del Fante (tbenr):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.
Enrico Del Fante (tbenr):Then we select the the 1st 8 that we get.
Enrico Del Fante (tbenr):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.
Enrico Del Fante (tbenr):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.
Enrico Del Fante (tbenr):So we have a baseline of aggregating aggregations, which is pretty fast in the order of 100 ms normally.
Enrico Del Fante (tbenr):and then we take the rest of the time a little bit to improve at improve that and and deliver the packing.
Enrico Del Fante (tbenr):We. We will run these experiments during these days and and crunch some data. Maybe we'll share.
stokes:Okay, thanks.
stokes: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
Parithosh Jayanthi:Maxib related activities, and Hoodie seems to be fine so far.
stokes:Okay, that's great to hear.
stokes:So with the consolidations in, does that round out all the different execution, request types.
Parithosh Jayanthi:Yeah, that should be. Yes.
stokes:Yeah, cool.
stokes:Thank you.
stokes:Okay.
stokes:so yeah, I mean, I think the main point we're getting at here is mean that timing for Petra.
stokes:I did want to call out Heleshke, because I guess that was another sort of basket of things that we had on the plate.
stokes:There are a series of non finality scenarios we wanted to test.
stokes:And yeah, I'm not sure anyone has much to add at this point
stokes:in terms of that topic exactly. But let's just keep it in mind as we move forward.
stokes:And
stokes: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.
stokes:I think since then there was some Async Comms around the State, maybe being a little aggressive given
stokes:the attestation analysis we were just talking about. Given the things we saw on Heleski, and to some extent sepulia with Petra?
stokes:Yeah. A number of.
Lion dapplion:I'm sorry.
stokes:I think. Let me mute that plan.
stokes:And yeah, a number of other bugs that have come up over the last few weeks. So
stokes: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
stokes:and hopefully finalize that one there. So how is everyone feeling?
stokes:Are we comfortable with this April 30th date, or do we want to push forward some amount of time?
stokes:Okay, there's some chat comments. Dustin says, yeah. Some bugs that came up.
stokes:There's a 30 days.
stokes:Yeah. So this was another point that came up essentially, having 30 days from the Confirmation date to the fork.
stokes:And I believe, okay, so we did have some
stokes:numbers here, let me pull up the table from A B khatoop.
stokes:I'll drop this in the chat. Okay, thanks, Tim.
stokes: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.
stokes:So okay, Teku, preference for mid-may.
stokes:And okay, thanks. Enrico. Oh, yeah, Shawn.
sean:Yeah, for lighthouse. We we agreed as a team that we could do may 7th so, or later. Obviously.
stokes:Okay.
stokes:So then, what do you think about May 7, th
stokes:if I'm reading the chart correctly here, I think May 7th would say, would give us even more than 30 days from today.
stokes:Okay, getting some consensus around May 7th in the chat.
stokes:Anyone opposed to May 7.th
stokes:Otherwise we'll lock it in.
stokes: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
Tim Beiko: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?
Tim Beiko:yes, because
Tim Beiko: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
Tim Beiko:April 21st or so. Such that we can put out the announcement like a proper 2 weeks in advance?
Tim Beiko:Or do people feel we need even more time than that?
Tim Beiko:I think 2 weeks.
Tim Beiko:It's probably reasonable. If yeah, if we have all the client teams releases.
stokes:Yeah. 2 weeks sounds good on the release cycle.
Tim Beiko:Okay?
Tim Beiko: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
Tim Beiko: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
stokes:Okay, let's do it.
stokes:So yeah, the confirmed date. So yeah, we'll go ahead and lock in May 7th for Petra on Mayna.
stokes:Seems everyone's okay with that.
stokes:And yeah, happy, Petra, everyone.
stokes: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.
stokes:yeah, and then otherwise, I believe, Tim said, April 21st would be releases.
stokes:and then 2 weeks later, will be the 7.th We'll have the fork.
stokes:Okay.
Gary Schulte:Hmm!
Gary Schulte:Anything else on.
stokes:Extra.
Gary Schulte:I thought I need another coffee.
stokes:Okay, if there's nothing else on Petra for now.
stokes:then, we'll turn to pure dos.
stokes: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,
stokes:are there any devnet? 5 updates worth mentioning?
stokes:Okay, yeah.
stokes:I think if you want more detail here, there is a breakout this week that I'd recommend checking out the recording of
stokes:essentially, our clients are just moving forward with different bugs as they come up there
stokes:and then. Yeah, moving towards Devnet 6.
stokes:So Perry here linked the specs in the chat. Thank you for that. And yeah, that's pretty much the latest there.
stokes:Okay, next up. Then I did want to at least call this out.
stokes:So one thing that we'll want to do
stokes:is with pure dos. Right? So we have the option to think about scaling the blobs
stokes:with Petra will be a 6, 9. Then the question is, how much higher do we want to go in Fussaka?
stokes:So
stokes: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.
stokes:And so you know from then that goes from 6, 9 to 8 times that
stokes:we could imagine just kind of rolling that out right. If it's right at the physical fork.
stokes: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
stokes: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.
stokes:So the schedule in the dock is the following, we would have Fusaka.
stokes: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,
stokes: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
stokes:you would implement this with this Bpo eip that each dreamer suggested. Let me grab the number.
stokes:It was 7, 8, 9, 2.
stokes:And the way this works is that you'd essentially have configuration. That says, Okay, at this epoch the
stokes:law parameters target Max, and then also the the feed divisor would be this.
stokes:add this next epoch. The blog parameters would be this, and then you just implement the increases this way.
stokes:So I think this is like a pretty straightforward and simple way to handle these increases.
stokes:You could imagine a more, you know, gradual mechanism, where, rather than like a doubling every 2 months, you have, you know, something
stokes:even sort of on the other end of the spectrum could be, you know some bob increase every week.
stokes: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
stokes:so either way, that was kind of a long spiel.
stokes:Does anyone have any questions for what I just said, or any comments on this?
stokes: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.
stokes:at least start moving towards something that we all like.
stokes: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
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
stokes:Yeah, that makes a lot of sense, Casey.
kasey: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.
stokes:Yeah, that's a nice idea.
stokes:And I didn't really touch on in the document that I posted. Because, yeah, I mean, what we don't want is.
stokes: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,
stokes:it would essentially mean shipping this new config to the entire network in a very short period of time.
stokes:So I think that's certainly a at least a concern with the strategy overall that we should think about more.
stokes:Presumably we would vet these numbers like, Oscar was saying, before you know, we move forward with them.
stokes: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.
stokes: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.
stokes:essentially having this be rather than have a programmatic schedule, you would actually just have this in the control of stakers.
stokes: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
stokes:have any comments express support.
stokes: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.
stokes:The right? Yeah. So just looking in the comments here people seem to lean towards this programmatic approach
stokes: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.
stokes:Then we have no way to increase the blog count further.
stokes:Okay, I guess one more comment here. Vitalik also suggested a different parameterization for the schedule.
stokes:I think this is something we can keep talking about. There was here. I'll just grab a
stokes:link here if people are interested.
stokes: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.
stokes:We have options here. We don't need to decide today, but something to be thinking about. So we can decide
stokes:over the next few months, I would say.
stokes:Okay, let's see, is Eve dreamer on the call.
ethDreamer (Mark):Yep.
stokes:Oh, yeah, anything you'd like to add around, because I believe you wrote 7, 8, 9, 2
stokes:anything else to highlight? There.
ethDreamer (Mark):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
ethDreamer (Mark):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
ethDreamer (Mark):nimbus might have trouble, but
ethDreamer (Mark):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
ethDreamer (Mark):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
ethDreamer (Mark):and that would change what the maximum size that a block can be. I don't think that's like
ethDreamer (Mark):a terrible thing, as you can just kind of set
ethDreamer (Mark):the Max. I think I don't know that it has to be exact, or you can and can write around it. But
ethDreamer (Mark):that was the only complexity I ran into. It was, it was fairly simple.
Dustin:Okay.
Dustin: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.
Dustin:I just brought in broad
Dustin: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
Dustin: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
Dustin:yeah, it it. It would look a little alien in the code base. But it's fine. Yeah.
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
stokes:which you know. This may take a little refactoring, but I think everyone is pretty strongly in favor of this Bpo strategy. So
stokes:that's what this implies.
Dustin: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
Dustin:driven by this again, this type system. We that sort of implicit
Dustin: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
Dustin:doable. Certainly, and that's
Dustin: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
Dustin:Do you try to upgrade everyone with short notice, or run into pre commitments, or all, all of that things set of things? But.
stokes:Yeah, that's
stokes: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
stokes:thinking about the stuff so that we can get there eventually.
Trent:Hey, Alex? Just to surface it. There's some discussion that maybe we can go back to
Trent:for release.
stokes:I was just about to circle back to that. Would you like to say something, Trent, or.
Trent:No no just.
stokes:Can. I can jump in.
Trent:Yeah. Go ahead.
stokes:Thank you. Yeah, yeah. There's a lot of stuff in the chat. Thanks for flagging it.
stokes:So yeah, I think there was some discussion here around the release date versus the main net date. So
stokes:main net would be main set. May 7.th And then the question is, do we want 2 or 3 weeks.
stokes: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
Lion dapplion:quite but ahead. But we can go for 3, and then if some client needs more
Lion dapplion:testing, they can delay the 2 weeks. I'm not sure if I think everyone else feels ready.
Lion dapplion:so we can target 3 and then do 2. If we need extra time.
stokes:Most
stokes: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
Tim Beiko:releases are out by April 14, th which is
Tim Beiko:which is like 10 days from now.
Tim Beiko: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.
Tim Beiko: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
Tim Beiko:and and often it's like, maybe a couple of days of lag. But
Tim Beiko:yeah, we should make this decision now.
Tim Beiko: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.
Tim Beiko:My sense is, that's like a reasonable amount of time for pretty much everyone to upgrade. But
Tim Beiko:I don't know.
stokes:Yeah, usually, we've done 2 weeks between releases and fork
stokes:and to your point. And I think to others points. It gives clients more time to look at the code
stokes:before having to ship a release. So 2 weeks
stokes: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
Tim Beiko: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.
Tim Beiko:I'm does that seem reasonable?
stokes:The Comms seems reasonable. And then I would suggest just to give 2 weeks in between releases. I mean that.
stokes:But it sounds like maybe we were asking for more time in between those.
Enrico Del Fante (tbenr):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
Enrico Del Fante (tbenr):spectra compatible, and then may release something in between that is, contains some some improvements that can be.
Enrico Del Fante (tbenr):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
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko:I would prefer that we have a blog post with the final releases.
Enrico Del Fante (tbenr):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.
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.
stokes:Okay? I mean, Barnabas is suggesting a more aggressive schedule.
stokes: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.
stokes:Barnabas, how strongly do you want the 16th day.
stokes:or do you have a reason for doing so?
Barnabas Busa:It's more like for just testing the stable releases.
Barnabas Busa:So having one extra week to Thursday minute releases, I think it possibly could be better.
stokes:I see.
stokes: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
stokes:must be ready by, say, the 21st at the latest blog post that day, or in the next couple of days.
stokes:That gives 2 weeks until Mainnet.
stokes: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.
stokes:Yeah, yeah, that's what I meant by the the rolling word, if that wasn't clear.
stokes:Okay, so are we comfortable with that schedule? So May 7th may net
stokes: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
stokes:If your release is ready earlier, that would help testing. So
stokes:if you're ready, don't be shy.
stokes:Okay. There's no disagreements.
stokes:Are we happy with the schedule now?
stokes:Otherwise, we're gonna ship it. So this is your last chance.
stokes:Okay, thank you.
stokes:Okay, so extra. Here it is next up. We have Fusaka
stokes:and okay, a number of well, let me say this first.st So.
stokes:Posaka, we had a deadline. What was it? March?
stokes:I think it might have been Monday or
stokes:last week, I forget. But either way there is a Pfi deadline that has passed.
stokes:Now the question is, what do we actually want to include in Fusaka Market Sfi, which is scheduled schedule for inclusion?
stokes:There's a number of eips that have been pfi'd so far. There's quite a long list
stokes:from there. Only a small subset are Cl. Things.
stokes:and at the same time clients have put out their preferences.
stokes:There's a number of them listed here on the agenda if you want to take a look.
stokes:And yeah, I guess the Tldr is that uniformly people want pure dos. And Bpo, which is 7, 8, 9, 2.
stokes:There are a few smaller things from there that clients either were considering, or that would be helpful.
stokes:I think, from here.
stokes:Let's hear from clients. If there are other things they'd like to include in Fusaka.
stokes:So I think we can agree, for now pure dos and the Bpo, eip.
stokes:Anything else anyone would like to propose.
stokes:and maybe to frame this a bit ideally, we can get to like a final cl.
stokes:as if I said. Today
stokes: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.
stokes:So
stokes: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.
stokes:Yeah. Sounds good asking if this is just the seal side correct.
stokes:And with regards to Uf, we decided last week that was going in.
stokes:Yeah, Mark.
ethDreamer (Mark):Yeah. So I would like to advocate for the proposure. Look ahead, eip,
ethDreamer (Mark):believe that's 7, 9, 1 7
ethDreamer (Mark):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
ethDreamer (Mark):consolidation
ethDreamer (Mark):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.
ethDreamer (Mark):So this makes the the proposer look ahead more unstable, which is difficult for
ethDreamer (Mark):pre-conf protocols to deal with. Now we've
ethDreamer (Mark):had some discussion about just how much more. This changes things.
ethDreamer (Mark):And we have found that it's it's actually
ethDreamer (Mark):kind of rare to change. Say, like the 1st slot in the the epoch.
ethDreamer (Mark):I ran a simulation of like 50,000 epochs, and didn't see it happen once, but
ethDreamer (Mark):of that 50,000 epochs 217,000 times
ethDreamer (Mark):an effective balance was changed between
ethDreamer (Mark):one epoch and another. So it it. The effect of balances. Changes definitely happen more frequently.
ethDreamer (Mark):This vip basically just takes like slaps an array into the beacon state and
ethDreamer (Mark):pre-calculates like during epoch processing, it pre-calculates all the composers for an epoch, and just appends them to the array.
ethDreamer (Mark):and it just reads from the array when closer to make it more stable.
ethDreamer (Mark):I did implement this in lighthouse. It
ethDreamer (Mark):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
ethDreamer (Mark):small it is. Even if the
ethDreamer (Mark):actual changing of the 1st proposer in the epoch is rare.
ethDreamer (Mark):It's still quite a problem for pre-comp protocols because they need to get the proposers
ethDreamer (Mark):for the next epoch on chain. And it's your classic crypto spectrum where
ethDreamer (Mark):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
ethDreamer (Mark):they can't really use crypto economics. Because
ethDreamer (Mark):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
ethDreamer (Mark):the proposers are in the next epoch, but that might occasionally change. You're gonna end up slashing someone who is participating honestly. So
ethDreamer (Mark):it kind of seems that their only viable options are to either have a proof
ethDreamer (Mark):or to use oracles, and the only way they can have a proof is, if
ethDreamer (Mark):we have the cip where the proposers are actually on chain, and then they can use the access to the
ethDreamer (Mark):this Beacon State roots to prove who the proposers are.
ethDreamer (Mark):And so I think that's probably the strongest argument for the cip is that
ethDreamer (Mark):these Protocols will be able to have a proof of who the proposers are, and then
ethDreamer (Mark):follow the rules of their protocol to know who their pre-comfer is.
ethDreamer (Mark):Yeah. So I'll just basically say, it's a very quick eip to implement
ethDreamer (Mark):it's not a huge change, and
ethDreamer (Mark):I think it's worth it for pre-comp protocols.
stokes:Alright. Thanks.
stokes:Yeah, Lynn, I know that you
stokes:we're working on this. Do you have anything that you'd like to add.
Lin Oshitani | Nethermind:Yeah. And I think that like, whereas it will like.
Lin Oshitani | Nethermind: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.
Lin Oshitani | Nethermind:And for all that. But
Lin Oshitani | Nethermind: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.
Lin Oshitani | Nethermind:And
Lin Oshitani | Nethermind: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.
Lin Oshitani | Nethermind:So yes, it'll be very nice if we can get this in.
stokes:Ahmad, you had your hand up. I don't know if that was.
Ahmad Bitar | Nethermind:Yeah, I was. Gonna yeah, I was just gonna say that.
Ahmad Bitar | Nethermind: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
Ahmad Bitar | Nethermind:someone posts the look ahead. And and then.
Ahmad Bitar | Nethermind: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.
Ahmad Bitar | Nethermind: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
Ahmad Bitar | Nethermind:optimistic and crypto economic slashing
Ahmad Bitar | Nethermind:for the look ahead. Mechanism. I yeah, just wanted to clarify. Why, that's very useful.
stokes:Thanks.
stokes:You know, top line.
Lion dapplion:Yeah. After doing the analysis, I convinced myself that this is rare, but I had chat
Lion dapplion:with Lee, and I think the the true argument for this feature is, as far as I understand, there's no way.
Lion dapplion:even with hacks, to to prove
Lion dapplion:if some pre-conf has actually submitted the wrong look ahead, or there has been this fumble in the protocol.
Lion dapplion:Therefore this would deter adoption of the feature.
Lion dapplion:and that directly affects the intention to move to becomes. So I I see, and I agree that
Lion dapplion:precomps are really important for the protocol to have based on native roll ups that are at parity with
Lion dapplion:more scalable. l. 1 s. And centralized sequencers.
Lion dapplion:Therefore this materially advances the roadmap.
Lion dapplion:There's the question of adoption. If
Lion dapplion:this technology will be adopted within the next year or within the next 2, but at least, judging from
Lion dapplion:the platform, like the sequencer calls, seems that this thing is quite down into the pipeline.
Lion dapplion: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
Lion dapplion:assurances.
Lion dapplion:For duplicate, that they will not have this negative lottery, of sometimes getting slashed. For no reason
Lion dapplion:we should adopt something like this.
Lion dapplion:And then for the topic of privacy.
Lion dapplion:Yes, this feature would, I think, neglect the possibility of doing Ssle as it's currently specced.
Lion dapplion:But the feature that is currently spec it's quite complicated. And I don't foresee
Lion dapplion:adoption of it due to the how expensive it is in terms of state bloat and competition overhead.
Lion dapplion:And I don't know. I'm
Lion dapplion:I'm hopeful that we can find a way in the in the future to to do it if we need to.
Lion dapplion:But the reality is precoms have to happen, and then we need to find another mechanism to ensure safety.
Lion dapplion:So yeah, I wouldn't. I wouldn't personally block this feature with for essentially.
stokes:Okay, any other questions or comments there.
Lin Oshitani | Nethermind: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
Lin Oshitani | Nethermind:like
Lin Oshitani | Nethermind: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
Lin Oshitani | Nethermind: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
Lin Oshitani | Nethermind:is a possibility to consider.
Lin Oshitani | Nethermind:And
Lin Oshitani | Nethermind:also, yeah, just, it's just that even in the cl clients. It's like an edge case where you always have to consider.
Lin Oshitani | Nethermind:And I think it just makes sense to.
Lin Oshitani | Nethermind:Yep.
Lin Oshitani | Nethermind: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.
Justin Drake:And on the increasing throughput side of things. You know, we have this whole massive roadmap around Das, and and that's
Justin Drake: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
Justin Drake:makes this proposition like very attractive to me. Now, one thing that was mentioned is around. You know, the the timelines for adoption.
Justin Drake:Adoption can only happen after we've
Justin Drake:we've actually shipped it and and built it. And I think, having
Justin Drake:this change will significantly shorten the the timelines for for shipping it, and therefore hopefully shorten the timelines for for adoption, as well.
stokes:Thank you.
stokes:Okay.
stokes:So I would say, Let's just keep this to the side. There were a few other
stokes:pfi vips to call out
stokes: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.
stokes: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
stokes: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?
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.
Anders Elowsson: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
Anders Elowsson: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.
Anders Elowsson: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.
Anders Elowsson: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.
stokes:Okay, thanks.
stokes: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.
stokes:Okay. Gotcha.
Anders Elowsson:But it's sort of a scale from a scaling perspective if you want to scale. So.
stokes:Right?
stokes:Okay?
stokes:yeah. I would suggest taking this to next week's call. There will be another round of this Cfi conversation
stokes:next week. So, yeah, but yeah, thanks for sharing today.
stokes:Okay, good gender. You wanted to bring up 7, 8, 9, 8.
Gajinder Singh:Yep,
Gajinder Singh:thanks, Alex. And so the idea behind 7, 8, 9, 8 is quite simple, basically in the big in the jumbo
Gajinder Singh:big blocks devnet. Basically, the issues that we saw
Gajinder Singh: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
Gajinder Singh: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
Gajinder Singh: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
Gajinder Singh:batching or parallelly transmitting
Gajinder Singh: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
Gajinder Singh:I think it is a pretty simple change
Gajinder Singh:in terms of concept as well as execution. Yeah.
ethDreamer (Mark):A, I don't think implementation. It's a simple change like
ethDreamer (Mark):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
Gajinder Singh:for blobs to be available.
ethDreamer (Mark):Even I didn't even get to the stage of implementing the 4 choice rules I was just implementing, separating the 2
ethDreamer (Mark):in 7, 7, 3, 2, and that took a long time. There's a whole separate block processing that has to be implemented.
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.
Potuz: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.
Gajinder Singh:So that is the second benefit.
stokes:You're there.
stokes:Thank you.
stokes: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.
stokes: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.
stokes:but I will just call it out. It was Cfi, or sorry it was, pfi, and yeah, so it's on on the table.
stokes:Anyone want to say anything briefly about this eip?
stokes:Okay?
stokes: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
stokes:Fusaka Sfi out of everything we've just covered.
stokes: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:Yeah, basically, what you said, this has been in the consensus spec for phase 0 for a while as well.
stokes:Okay, cool.
stokes:So in terms of Sfr.
stokes:we have, I think, unanimous consent around pure dos and Bpo as a strategy to bump up the blobs
stokes:everyone. Okay, Otis, would you like to then say something about 7, 7, 3, 2.
stokes: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
Potuz:peer does this year. By the end of Q. 3 start of Q. 4.
Potuz:I agree, and I won't have any complaints.
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.
stokes:Ideally, by the end of the year mark.
ethDreamer (Mark):Yeah, I just wanted to say for the Bpo eip, like.
ethDreamer (Mark):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
ethDreamer (Mark):a specific, a way of specifying
ethDreamer (Mark):that's specced in the eip. But, like, if anybody has better ideas like I'm all ears.
ethDreamer (Mark):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.
stokes:Okay, yeah. And I think those sort of details at that level are still open for discussion.
stokes:I would like today just to agree on that strategy. And yeah, I think the configuration approach you gave makes a lot of sense.
stokes:Okay.
stokes:So back then, to an Sfi set, we would have Puertos, Bpo, eip.
stokes:And
stokes: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
stokes:it did seem like there is quite a bit of support for 7, 9, 1 7,
stokes:which was the proposal. Look at the IP.
stokes: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.
ethDreamer (Mark):In terms of people that voiced in this call so far. Yes, I mean.
Potuz:I assume, pre-confert as well.
ethDreamer (Mark):Yeah. And Teku, this blog post said something like that.
ethDreamer (Mark):Their main consideration and other eaps is just
ethDreamer (Mark):disruptive. The changes and that they're open to eips that don't delay the fork, so I'd assume there are.
ethDreamer (Mark):But yeah, anyway, they seem compatible.
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.
Potuz:We're making a decision like this for the next fork. Now, this.
Potuz:Yeah, this is just out of what we typically do.
stokes:Okay, yeah, Tim, could you say more about Cfi versus Sfi.
Tim Beiko:Yeah. So I agree, we like.
Tim Beiko: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.
Tim Beiko: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
Tim Beiko: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
Tim Beiko: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.
Tim Beiko: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
Tim Beiko:yeah, that proposal is like we don't
Tim Beiko: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.
stokes:Okay, yeah, I think I was getting ahead of myself and missing the Cfi stuff.
stokes:So I agree with the approach you laid out.
stokes:I also agree that yeah, the cip is pretty new and some more time to let it bake would be good.
stokes:So and for today, let's just focus on Cfi
stokes: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.
stokes:Okay?
stokes:So then, in terms of Cfi. Oh, sorry. Did you have a comment on this.
Saulius Grigaitis | Grandine: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
Saulius Grigaitis | Grandine:This feature is a good example of
Saulius Grigaitis | Grandine: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
Saulius Grigaitis | Grandine:development
Saulius Grigaitis | Grandine: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,
Saulius Grigaitis | Grandine: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
Saulius Grigaitis | Grandine: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.
stokes:Alright. Thanks.
stokes:So okay, then, we have peardos that's sified in terms of Cfi.
stokes:Would you like to go ahead and make 7, 9, 1 7 cfi.
stokes:That gives the 7, 9, 1, 7 champions more time to work on test analysis. It gives other
stokes:participants time to consider the feature in more depth.
stokes: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?
stokes: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.
stokes:So with that context, are we okay with moving 7, 9, 1, 7 to Cfi.
stokes:okay, no one is disagreeing. So let's go ahead and do that.
stokes:Otherwise, let's see. Okay, so then
stokes:there is enders Eip that will be touched on next week.
stokes:And what else did we have?
stokes:We did bring up 7, 6, 8 8
stokes: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.
stokes:Yeah.
stokes:anyone want to move?
stokes:7, 6, 8, 8, 2 cfi.
stokes:or do we just want to table that for now?
stokes:Okay, right. Bpo, so I think
stokes:I think, given the process right now, Bpo will make more sense to Cfi.
stokes: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.
stokes:Let's move Bpo to Cfi.
stokes:Everyone. Okay with that.
stokes:Okay, I'll assume. That's yes.
stokes:Peer to us. Vpo, 7, 9, 1, 7.
stokes:Okay.
stokes:Anything else we should clarify today.
stokes:Okay.
stokes:Great.
stokes:Then, okay, we have a few minutes left, and there is one more eip because we love the Ips.
stokes: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.
stokes:but more a new body of work that Mike wanted to introduce.
mikeneuder: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.
mikeneuder: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
mikeneuder:which is the exit queue. So
mikeneuder: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
mikeneuder:I guess, like, let's let's talk about today. Pre Petra, because,
mikeneuder: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.
mikeneuder: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
mikeneuder: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
mikeneuder:you know, if there's a bunch of withdrawals that want to happen. Concurrently they have to get spread out and kind of
mikeneuder:distributed over the many, many future epochs rather than processed immediately.
mikeneuder: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
mikeneuder: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.
mikeneuder: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
mikeneuder: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
mikeneuder:validator exits. Eli. 5. Which kind of talks about how the changes are
mikeneuder: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.
mikeneuder: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.
Mallesh: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
Mallesh: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.
Mallesh: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.
mikeneuder: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
mikeneuder: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.
mikeneuder:these withdraws might be kind of very bursty in the case of like market, like big market volatility. Events right like
mikeneuder:tariffs being announced, could could require a bunch of people to need to need to get out quickly. And
mikeneuder: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
mikeneuder: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
mikeneuder:in the same set of in the same group. And as a result, basically, full withdraws have.
mikeneuder: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.
Mallesh: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
Mallesh: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,
Mallesh:you know, work around the hard constraint which is the sweep. Constraint adds, multiple days potentially.
mikeneuder: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
mikeneuder:yeah, that's probably where I'll leave it.
stokes:Cool. Thank you very much.
stokes: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
stokes:that we just up here. Right? Okay.
mikeneuder: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
mikeneuder:is is useful on, on, I guess.
mikeneuder:Specs spec level. But yeah, they could be combined into one eap to like, overhaul the the queue generally.
stokes:And you just mean, like different queues for full versus partial withdrawals.
mikeneuder:Yeah, that's the simplest one, right?
stokes:Cool any other questions.
stokes:If things come up Async, should they go to the E 3 search post? Or is there a better place.
mikeneuder: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!
stokes:Cool. Thank you.
stokes:Okay, we're basically at time.
stokes:any closing comments. I think we got through everything today. And also, I think, made a lot of good progress towards Petra and Fusaka.
stokes:Okay, then, thanks everyone. I'll see you next time.
Ansgar Dietrichs:Thank you.
Ansgar Dietrichs:One thing.
Mikhail Kalinin:Thank you.
ethDreamer (Mark):Thanks guys.
Chat Logs
00:00:20
stokes:https://github.com/ethereum/pm/issues/1399
00:00:28
Justin Florentine (Besu):goooooooood morning consensus layooooors
00:04:02
Barnabas Busa:you could fill up the queue, exit, fill up the queue, exit
00:04:43
Barnabas Busa:we did 700k validator topup, 1ETH each on holesky. Thats gonna take quite a while to dequeue.
00:05:43
Barnabas Busa:it will take about 1/2 year to dequeue all these.
00:05:46
Parithosh Jayanthi:https://ethpandaops.io/posts/hoodi-attestation-packing/
00:05:52
Parithosh Jayanthi:https://discord.com/channels/595666850260713488/892088344438255616/1357271429720051752
00:06:41
Parithosh Jayanthi:Terence’s doc: https://hackmd.io/@ttsao/attestation-packing-pectra
00:10:25
terence:nice nice, that is better than the prysm way
00:13:46
Dustin:arguably more important than the att stuff is some real consensus issues, multiple of them
00:13:52
nixo:I will reiterate: several members of the community asked for 30 days and if we confirm the date today, it’s less than that
00:13:59
Fredrik:I suggest +30 days as agreed earlier
00:13:59
Dustin:now fixed but discovered late
00:14:04
Enrico Del Fante (tbenr):In teku we have a preference for mid May
00:14:19
Tim Beiko:Options here: https://github.com/ethereum/pm/issues/1374#issuecomment-2741823829
00:14:49
Enrico Del Fante (tbenr):2025-05-14 or 2025-05-07 for us
00:15:08
Josh Davis:From YouTube “Clara van Staden
Would prefer May 7, Given that we need about 30 days to pass upgrade referendum”
00:15:18
Barnabas Busa:may 7 LFG
00:15:21
Tim Beiko:I like May 7 😄
00:15:24
Tim Beiko:Any EL teams have concerns?
00:15:26
Som - Erigon:May 7
00:15:32
Phil Ngo:Ok with May 7th for us. I think we want to ensure Prysm, Teku and Lighthouse are comfy
00:15:51
terence:May 7 is fine with us
00:15:55
Parithosh Jayanthi:LFG May 7th
00:15:57
Enrico Del Fante (tbenr):👍
00:16:03
Ahmad Bitar | Nethermind:👍
00:17:53
Julia:Is this the confirmed date now?
00:18:09
spencer-tb:May the 7th be with you
00:18:22
Will Corcoran:Happy Ether
00:18:33
Lion dapplion:May 7th ok
00:18:43
Trent:LFG
00:18:56
Barnabas Busa:someone already celebrating
00:19:09
Trent:Gary u were unmuted shameeee
00:19:18
Parithosh Jayanthi:Specs: https://notes.ethereum.org/@ethpandaops/peerdas-devnet-6
00:19:49
Will Corcoran:https://github.com/ethereum/pm/issues/1415
00:19:53
Will Corcoran:Breakout agenda
00:19:53
Parithosh Jayanthi:The kurtosis config already works
00:19:55
Parithosh Jayanthi:So you can test stuff
00:20:04
stokes:https://hackmd.io/@ralexstokes/blob-acc-2025
00:20:20
Lion dapplion:Releases when?
00:22:01
Tim Beiko:April 22nd at the latest, ideally 21 or earlier.
00:22:38
Ansgar Dietrichs:I do like this “programmatic step-wise ramp-up” plan. But we should set the endstate maximum based on the empirical devnet stability close to the fork. only go to 48/72 if we have that stable on devnets by fusaka.
00:22:40
Tim Beiko:By then, please also fill out who from your team will be on call for the release: https://github.com/ethereum/pm/blob/master/Pectra/pectra-mainnet-plan.md
00:22:58
Tim Beiko:Replying to "I do like this “prog..."
It depends how far out we set the schedule
00:23:43
Parithosh Jayanthi:Replying to "I do like this “prog..."
Btw re: your call to get more data on peerdas testing, its available here: https://discord.com/channels/595666850260713488/1252403418941624532/1357199183395819623
00:23:52
Dustin:+1 yeah, to no precommitments of that sort, it creates fake emergency
00:24:25
Tim Beiko:+1 on a rollback of the limit
00:24:40
Barnabas Busa:isn’t this what testnets are for?
00:24:45
Ansgar Dietrichs:can’t we use testnets for rollback testing?
00:24:54
Tim Beiko:Yes, but we should test it before 😄
00:25:14
Ansgar Dietrichs:Replying to "Yes, but we should t..."
agree, also to make sure we understand how to do it fast. but I do think testnets are a better place for that
00:25:16
kasey:Yes we should do testnets of course. My concern re testnests would be that there is software only running in production.
00:26:03
Lion dapplion:Only 2 weeks for the network to update feels short? Why not call for releases a week before?
00:26:06
Barnabas Busa:programmatic ++
stakers —
00:26:09
Enrico Del Fante (tbenr):We like a simpler approach
00:26:11
Roman:+1 to programatic. having stakers vote would just be coordination overhead
00:26:11
Ansgar Dietrichs:seems like the staker control could add complexity? how simple is that?
00:26:14
kasey:Replying to "Yes we should do tes..."
And it would be good to discover mainnet issues without some other issue ongoing.
00:26:17
Enrico Del Fante (tbenr):Which is programmatic 🙂
00:26:43
nflaig:Replying to "Only 2 weeks for the..."
+1 this two week time windows makes no sense
00:26:49
Ben Adams:Ideologically stakers would be better; practically programmatically would be better
00:26:57
Trent:Echoing this, but Tim might have context from the other upgrades?
00:27:05
stokes:https://github.com/ethereum/pm/issues/1399#issuecomment-2762101549
00:27:16
Ansgar Dietrichs:well there would be the Erigon-style option of validator control, but with a programmatic ramp-up of the voting defaults in clients
00:27:43
Ansgar Dietrichs:Replying to "well there would be ..."
I would not actually hate that idea, main worry would be complexity
00:28:14
Tim Beiko:Replying to "Only 2 weeks for the..."
Shapella was about 2 weeks, so was Dencun
00:28:28
Trent:Replying to "Only 2 weeks for the..."
Should it be 3 tho?
00:28:36
Barnabas Busa:Could we actually agree firmly that we need BPO, don’t care about specifics, but we should stop going back and forth on it.
00:28:46
stokes:Replying to "Could we actually ag..."
Seems like we are on this page today
00:28:56
Tim Beiko:Replying to "Only 2 weeks for the..."
I’m fine with whatever, but if client teams are concerned, can you please raise it on the actual call rather than side comment in the chat 😅?
00:29:16
stokes:Replying to "Could we actually ag..."
Can make explicit call out in next section with SFI’d EIPs
00:30:54
Barnabas Busa:could it be done without delaying the fork?
00:31:19
Tim Beiko:I updated the Meta EIP with the new timestamp. Can I get a couple +1s before merging 😄 ?
https://github.com/ethereum/EIPs/pull/9560
00:31:21
ethDreamer (Mark):Replying to "could it be done wit..."
I did it very quickly so yes
00:31:49
nflaig:Replying to "Only 2 weeks for the..."
wait I thought we are talking about having the first bump in BPO fork after 2 weeks 😅
00:31:53
ethDreamer (Mark):Replying to "could it be done wit..."
Like it was a couple hours and a big part of that was because I don’t know the reth codebase
00:34:16
Barnabas Busa:client teams can already make releases today :D
00:35:44
Barnabas Busa:Would any client teams feel uncomfortable having mainnet releases out by 16of April?
00:36:32
Chris:Aren't client teams still working on the attestation packing? I'm not sure clients are ready today
00:36:58
Tim Beiko:Client teams can also put out releases before the EF blog post goes out :-D
00:37:03
Barnabas Busa:Replying to "Aren't client teams ..."
EL teams don’t have to deal with that. Heard @lightclient is keen.
00:37:18
Dustin:these "early versions" aren't that useful, if the plan is to do day-1 patches just wait
00:37:22
terence:why not just define the minimal time that clients have to release by and if teams want to release earlier then release earlier
00:37:53
Barnabas Busa:Replying to "why not just define ..."
lets make that 16th of April.
00:38:03
Barnabas Busa:Replying to "why not just define ..."
2 weeks from now, 3 weeks before the fork.
00:38:21
Barnabas Busa:Replying to "why not just define ..."
And then the blog post can go out on 16th as well.
00:38:26
lightclient:so mainnet releases by april 16 ?
00:38:43
Mario Vega:Replying to "Would any client tea..."
We haven’t made a release from tests with these EIP changes:
https://github.com/ethereum/EIPs/pull/9508
https://github.com/ethereum/EIPs/pull/9582
It’s a very simple client change, but tests take longer
00:38:51
Tim Beiko:Replying to "so mainnet releases ..."
Mainnet blog post going out on April 22
00:39:08
Tim Beiko:Replying to "so mainnet releases ..."
Clients can do whatever they want, but if no releases by EOD April 22, you’re getting a “TBA” in the blog post 😄
00:41:29
Mario Vega:Replying to "Would any client tea..."
Although it’s unlikely that something comes out of this due to the unrealistic scenario so we should be ok
00:43:39
Ansgar Dietrichs:so this is just about the CL side, right? so this is unrelated to EOF?
00:44:28
nixo:https://eips.ethereum.org/EIPS/eip-7917
00:46:10
ethDreamer (Mark):https://github.com/ethDreamer/lighthouse/compare/unstable..deterministic_proposer_lookahead
00:46:53
Barnabas Busa:any reason to do this at epoch transition instead of sometime in the middle of the epoch? Feel like beacons do already enough computation on epoch transitions.
00:49:24
Potuz:Anyone working at whisk/SLE care to say something here?
00:51:50
stokes:Replying to "Anyone working at wh..."
You could do this with some kind of validator privacy
00:51:57
stokes:Replying to "Anyone working at wh..."
Its not simple though
00:52:50
Potuz:Replying to "Anyone working at wh..."
Problem I see is that this has been in the works for years and ditching years of work on something that was just proposed seems rushed
00:53:02
ethDreamer (Mark):Replying to "Anyone working at wh..."
Current SSLE construction is also not quantum secure
00:53:06
Potuz:Replying to "Anyone working at wh..."
Without hearing the other side and instead of “hoping” actually having research
00:53:32
Francesco:Replying to "Anyone working at wh..."
Tbf SSLE hasn’t been actively worked on for a while, no?
00:53:44
Potuz:Replying to "Anyone working at wh..."
There are pushes on those branches regularly
00:53:53
Francesco:Replying to "Anyone working at wh..."
Ok not something I follow, sorry
00:53:55
Potuz:Replying to "Anyone working at wh..."
I am not against this for the record, I think it’ s a useful feature
00:54:09
Potuz:Replying to "Anyone working at wh..."
I just don’t like the timelines by the reasons mentioned above
00:54:25
stokes:Replying to "Anyone working at wh..."
Which timelines?
00:54:29
mikeneuder:https://hackmd.io/TS7ieyruQO6faT_nsf95mA
summary doc of how the lookahead calc works if anyone forgot. i had to remind myself…
00:54:36
Potuz:Replying to "Anyone working at wh..."
Problem I see is that this has been in the works for years and ditching years of work on something that was just proposed seems rushed
00:54:38
mikeneuder:IBRL ? lol
00:55:54
Gajinder Singh:I want to propose: EIP-7898: Uncouple execution payload from beacon block to allow CLs to deal with bigger payloads from pumping the gas
https://eips.ethereum.org/EIPS/eip-7898
00:56:22
Anders Elowsson:EIP-7918 https://ethereum-magicians.org/t/eip-7918-blob-base-fee-bounded-by-execution-cost/23271
00:56:53
stokes:Replying to "I want to propose: E..."
Ok, can say something after anders
00:57:44
Ansgar Dietrichs:seems like a reasonable change, but would be EL side, no?
00:58:49
Ansgar Dietrichs:agree that “spiritually” any changes related to blobs have a CL connection :-)
00:59:08
Anders Elowsson:Replying to "agree that “spiritua..."
Hehe that’s my angle
00:59:51
Dustin:waiting for blobs is a mess
00:59:57
Dustin:it took months to sort out
01:00:22
Dustin:and I mean, across the ecosystem, it wasn't any one client
01:00:34
Potuz:https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7918.md
Cause magicians is dead
01:00:37
ethDreamer (Mark):This is a massive change. Decoupling the ExecutionPayload from the BeaconBlock was most of the work of implementing EIP-7732
01:00:45
Dustin:it is not a "simple" change
01:00:46
iPhone:I don’t understand what the CL does when they don’t have the payload — they optimistically assume it will come or block until they get it?
01:00:49
Dustin:in any way
01:01:52
Lin Oshitani | Nethermind:Replying to "any reason to do thi..."
Yeah, I think it would be ok to do it few slots into the epoch. It's for the next epoch, so doesn't have to come ASAP. Especially if the computation is already heavy at epoch transition.
01:02:12
Anders Elowsson:Replying to "https://github.com/e..."
Thanks. Actually working from this morning, super snappy
01:02:34
Lion dapplion:Agree with Potuz, we have better solutions available
01:02:53
Lion dapplion:This one https://ethresear.ch/t/faster-block-blob-propagation-in-ethereum/21370
01:04:05
mikeneuder:@alex could i also talk about 7922 ? just need a few mins
01:04:10
mikeneuder:https://ethresear.ch/t/adding-flexibility-to-ethereums-exit-queue/22061
01:04:10
stokes:Replying to "@alex could i also t..."
Yes at the end
01:04:13
mikeneuder:Replying to "@alex could i also t..."
o ok
01:04:21
Potuz:For the record 7732 was also PFId
01:04:37
Potuz:no
01:05:12
Parithosh Jayanthi:Feature freeze peerDAS asap, harden and ship 😄
01:05:16
Potuz:yeah
01:05:47
Potuz:But if we open the can of worms of other EIPs that haven’ t been implemented at least myself will be with a knife fighting for 7732
01:05:49
Ansgar Dietrichs:ideally by end of Q3, no? “ideally by end of year” sounds like already planning with next year
01:06:04
Potuz:Replying to "ideally by end of Q3..."
Yes end of Q3
01:06:10
Potuz:Replying to "ideally by end of Q3..."
That’s our timeline
01:06:50
sean:Lighthouse supports it
01:06:58
Toni Wahrstätter:For BPO, would be nice to have the blob basefee update fraction be calculated in protocol instead of having different constants in the config.
01:07:12
mikeneuder:“researchers” is a slur now lol
01:08:12
Tim Beiko:I would only CFI it, not SFI?
01:08:19
lightclient:Replying to "“researchers” is a s..."
“now” ? 😆
01:09:03
Ansgar Dietrichs:if we were to include it, I would propose we agree to be very willing to kick it back out, if it looks like it causes trouble on implementation / testing / anywhere it could delay Fusaka
01:09:08
Potuz:After having to read in Keybase weekly about consensus critical bugs in several clients, I am definitely against rushing any EIP that has just appeared and most of us haven’t even seen
01:10:26
Potuz:yes
01:10:59
Tim Beiko:TBF it wasn’t clear that the “deadline” was for SFI or CFI. I’ve convinced myself this week that using the deadline to separate PFI/CFI and then devnets to separate CFI/SFI 😄
01:11:18
stokes:Replying to "TBF it wasn’t clear ..."
Yeah, this feels like the right method
01:11:22
kasey:In one of the prysm fulu recommendation drafts I suggested a new prioritization scheme. CFI is too 1 dimensional. We need to have a defined distinction between Required (fork is delayed if it isn’t done) and Stretch “These are features that client teams broadly agree are important, but not so critical that the fork should be delayed until they are ready. “
01:12:07
Tim Beiko:Replying to "In one of the prysm ..."
SFI should be our list of “required for the fork"
01:12:09
Francesco:Replying to "In one of the prysm ..."
Are features that easy to pull out though? Feels like in the past we’ve often said “it would be harder to take it out than just go through with it at this point”
01:12:26
Tim Beiko:Replying to "In one of the prysm ..."
@Francesco I think pulling out gets more complex as we have more features introduced at once.
01:12:28
Ansgar Dietrichs:Replying to "In one of the prysm ..."
@Tim Beiko but EOF is a good example. It is SFI, but everyone agrees that the fork would not wait for it
01:12:38
Danno Ferrin | Ipsilon:Replying to "In one of the prysm ..."
In a different software industry I’ve seen the separation called “Release Drivers” and “Features of Opportunity”. Release drivers can cause deadlines to be dropped. Deadlines can cause features of opportunity to be dropped.
01:12:55
Tim Beiko:Replying to "In one of the prysm ..."
@Ansgar Dietrichs fair, but I also think we’re struggling with 3 buckets right now, so I’m skeptical of adding more yet
01:13:17
Potuz:Replying to "In one of the prysm ..."
Getting features out after implementing is indeed a problem quite often
01:13:30
ethDreamer (Mark):I like it
01:13:32
kasey:Replying to "In one of the prysm ..."
Actually in my full def I had something about pulling out features: "They don't interact with the required features in a way that could pose a risk to the timeline due to excess complexity in testing, or implementation details that would make them difficult to remove as we approach the fork. Ideally these are totally orthogonal to the EIPs in required."
01:13:47
ethDreamer (Mark):Does this mean BPO is CFI or SFI?
01:13:51
kasey:Replying to "In one of the prysm ..."
So we would not include things in stretch if there was any possibility of them interacting with a required eip
01:14:07
stokes:Replying to "Does this mean BPO i..."
One sec
01:14:53
Enrico Del Fante (tbenr):We are agnostic on 7688. We have it ready. And we are ok if we want to CFI it
01:15:29
NC:Same with Lodestar, we have already implemented 7688. Not opposed to CFI it
01:15:33
ethDreamer (Mark):I want to point out that the fusaka fork has no changes to consensus data structures that would impact proofs even if 7917 is included
01:16:09
ethDreamer (Mark):Replying to "I want to point out ..."
Or at least that’s my understanding rn
01:16:14
nixo:was already posted but reposting cuz it’s far up now: https://ethresear.ch/t/adding-flexibility-to-ethereums-exit-queue/22061
01:18:31
Danno Ferrin | Ipsilon:How do we prevent the exits from becoming 16*(M+1) exits in one block, and then M blocks of empty exits, repeated until the exit queue is empty?
01:18:40
Julia:Can you share the link to your slides?
01:18:44
mikeneuder:https://ethresear.ch/t/adding-flexibility-to-ethereums-exit-queue/22061
01:18:55
mikeneuder:https://hackmd.io/@mikeneuder/eli5-ethereum-validator-exits
01:19:35
nixo:lol
01:19:51
Ansgar Dietrichs:danny in the chat 😢
01:20:28
Julia:Sorry I just dropped - did you share any other links other than this one https://ethresear.ch/t/adding-flexibility-to-ethereums-exit-queue/22061 ?
01:20:30
Potuz:Testing this will be fun
01:21:14
Josh Davis:Replying to "Sorry I just dropped..."
https://hackmd.io/@mikeneuder/eli5-ethereum-validator-exits
01:21:19
Julia:How much faster?
01:21:32
Mallesh:Replying to "How much faster?"
8x was what we proposed
01:21:50
Julia:Replying to "Sorry I just dropp..."
thanks!
01:22:07
Mallesh:Replying to "Sorry I just dropped..."
There's also a draft eip fwiw
01:23:36
Ansgar Dietrichs:I do think that going forward we should focus less on shipping staking features, and more on features for real users (DA for L2s, FOCIL, delayed execution / ePBS, …)
If there is still room in Glamsterdam, this does seem like a nice-to-have
01:23:49
Julia:are these changes post pectra or in pectra?
01:23:57
Parithosh Jayanthi:I nominate potuz to test this
01:24:25
Josh Davis:Replying to "are these changes po..."
Post-Pectra
01:24:26
Julia:great stuff
01:24:39
Julia:that completely changes the game 🎉