All Core Devs - Consensus #168

Transcript

Alex Stokes: Hello! Can people hear me okay?

Josh Davis: Yep, unclear.

Alex Stokes: Okay, cool. Okay, yeah, sorry, I had to grab some other headphones. Let's see, we have, I think, enough people to get started. So yeah, Josh, if you're helping with the stream, I'm ready when you are.

Josh Davis: Alright, you are alive.

Alex Stokes: Okay, thanks, everyone. Welcome to ACDC number 168. This is issue 1772 in the PM repo. And… Yeah, should have a pretty exciting call today. We'll review what's happened on the Vusaka side of things, with an eye towards officially confirming our mainnet dates. And then we can transition into Glamsterdam and discuss a number of EIPs there to continue scoping that fork. So… Let's go ahead and get into it. First up, I believe, you know, some major events since our last call, would have been Sepolia going to BP02, and then Fusaka happening on Hoodie. I see Perry's here. Maybe he can give us some updates on what he's seen? Also Barnabas. Yeah, okay, thanks.

Parithosh Jayanthi: So, for, Superior BPO2, it went smoothly. We haven't necessarily seen any, issues. Also. We are looking at all of our data being collected, and there's a huge bias towards SuperNodes and Sepolia, which makes sense, considering every validator's probably a super node, and everyone providing RPC is a supernode. The hoodie data is a bit more interesting. We do have a better distribution of, custody columns on Hoodie. The fork on Hoodie itself also went perfectly fine. There was a small drop in participation, most of it attributed to, operator issues. However, there was this one lead bug that was found, and I let the lead team expand on that a bit later. But in the meantime, we've… they've already patched the…

festivalista.

Alex Stokes: Okay, great. And I guess, yeah, zooming into the REST bug a minute, it sounds like it was a combination of some edge cases. I guess it'd be good to also… Yeah, at least explore if we could have a static test for this. I'm not sure if that was… If it's really something that's, well addressed by that format of test.

Parithosh Jayanthi: So, we had tested this scenario in the past, but the outcome is basically an orphan block, and I guess we didn't necessarily miss… we missed this, In that scenario. So we're talking to the testing team, and I think we will have a explicit test for this. There were just some details that they were figuring out, and I see PK's on the call. He was the one who figured out the sequence of events, so maybe… You want to speak, PK?

pk910: Nothing really to add there, yeah.

Alex Stokes: Okay. That works then. Cool, okay, well, nice find. And yeah, it seems like they already have it patched, so… That's good. Okay, otherwise, yeah, it looks like things have been going pretty well. Anything else on the forks? Or more generally on Fusaka. If not, I think we can go ahead and discuss mainnet dates. So… excuse me. So, yeah, on the last ACDC, I wanted to start this ball rolling, just so that, yeah, we could basically move ahead today. Because the proposal would be following, this original dark, doc from Barnabas that… here, I'll grab this link… But ultimately, would say mainnet releases out, November 3rd, which is, I believe, Monday, and then we'd have the fork one month from then, so that would be December 3rd, for Foostock on Mainnet.

Along with that, there's dates for the BP01 on Maynet, that would be on December 9th. And BPO2, that would be January 7th of next year. So… Again, last ACDC, people were generally on board. Didn't seem like there were being issues with that. We checked again on ACDE last week. People are okay with that. Following the process doc that we have, you know, we really… if we're following the letter of it, we should wait until today to actually officially set the dates. So, I'd suggest we do that now. And… yeah, again, I think everyone is on board at this point, so… any reason not to do it? Otherwise, we'll lock that in and kick off Everything we need to do there.

Anya?

Emmanuel Nalepa: Yeah, hi. So the rings are… who did fork, so some user reported some bugs we, for some reason, didn't see on Holesky, or Sepolia, or testnets, or DevNets. Rough. Some of them are, fixed, or… Are going to be fixed, and for at least one bug, we don't have the root cause yet. For example, this bug is, yes, is, after a few hours. Prism Nodes tends to… kick out. non-present peers, and so after a few hours, the prism has only prism pairs. We don't have a fix yet, and for that reason, it's very likely we cannot… release on, next Monday.

Alex Stokes: Okay Hmm. Okay, maybe we'll circle back to that. Is everyone else okay with, these dates?

Emmanuel Nalepa: I'm not saying we should, we should delay the mainnet, but I'm just saying that it's unlikely we release on Monday.

Alex Stokes: Yeah. Yeah, which is maybe okay. Like, especially if we get something, you know, at some point next week, I think that still is enough time for people. Okay. Would you be okay, then, if we went ahead with these dates, that we have as is, and… Yeah, I mean, worst case then, like, something… Would become a deeper issue than we expect, and then we would need to adjust, which we could do. There just might be some thrash with everyone else trying to get ready.

Emmanuel Nalepa: And so, yeah, iPhone is asking if I can say why it is only surfacing now. I cannot at the moment. We didn't see this issue on, you know, DevNet or, say, Polya and Holesky. We are still investigating.

Alex Stokes: Yeah, sounds like it'd only really become apparent on a hoodie. Which is, you know, interesting. I think Hoodie has a much more realistic, node distribution than the other testnuts, so… Okay. I think if you're okay with it, that's what I would say, is just go ahead and move ahead with this, and yeah, we'll just keep an eye on it. If we need to adjust, then we can adjust.

Emmanuel Nalepa: Yeah, I agree with Justin about keeping mandate dates and delay release from prison.

Alex Stokes: Copp. Okay, then in that case, let's see… I think, let's see, Nimbus… I'm not sure if anyone from Nimbus is here. Or Grand Dean, if they're around. Okay, well, as far as I know, they wouldn't have any issues with this. So, let's go ahead and do that. And… yeah, Prism team, we'll just wait for your release as soon as we can get it. Otherwise, yeah, let's go ahead and do this. There's a number of other places, the Meta EIP, there's this process doc for Fusaka. That will have all this information. And, yeah, one more note on that,

you know, we set up the structure, with Pectra, and just wanting a little more clarity around, you know, if there is an incident, how would you respond to it. So I will be reaching out to everyone to, essentially get a point person per team, so that will go in the PR. And… then we should be good there. And otherwise… yeah, I think we're good to go. So, again, I know everyone, this was, a big lift to get this together by this point in time, so thank you for that. This is a really cool fork. the people I've talked to in the community are very excited about it, and yeah, it's a really big deal, so…

Super exciting. And yeah, let's just then focus this next month on getting a safe upgrade to Mainnet. Cool. Okay, thanks everyone for the updates there. I did want to circle back to this one last thing for Fusaka. Barnabas had a suggestion to this process doc I was just referring to, and, essentially, okay, so the language we have today is that mainnet should not have an upgrade date set until all testnets have been upgraded, that's what we've been doing. He essentially proposes to change the language such that, we only need at least one testnet, and There's some discussion on the PR if you want to check this out. I think the feedback is a bit mixed, and I kind of tend to agree, like.

I hear what Barnabas is trying to do, just to give us some more flexibility around setting the date versus having to go through all of these testnets. Again, of course, you know, I think the… Ambient context here to keep in mind is, like, obviously, if there's an issue, we, like, would not just blindly move ahead with mainnet. Yeah, so, in any case, I don't know if anyone wants to say anything else about this, at the moment. But also, yeah, I… I'm not sure we want to merge this as is. Ben?

Ben Adams: Isn't a more important thing not the… Waiting for the testnet to set a date, but… The distance from the testnet going live to when the mainnet date is. If you say to me. That period between the two, rather than… When we decide on the date.

Alex Stokes: Mmm… Perhaps. So, I mean, the thing we definitely want is one month between the date and Maynet. And… I believe the intent here is just to have the ability to… You know, essentially all agree on what the date would be, even if the testnets haven't forked. That way we can move things forward, kind of like we were trying to do this time, where, you know, Especially given the timing here, where, like, presumably we'd have releases out on Monday, or, again, sometime next week. I, you know, I wouldn't want to come and propose this, for example, on this call, being like, hey everyone, by the way, like, get a release out in a few days, over the weekend.

So that's, you know, that's where we're trying to find the balance of the language here, just to give us the flexibility to avoid, you know, very short turnarounds. But yeah, so… I think in that case, we'll just let this simmer a bit more. If I find a minute, maybe I'll try to think of some… Yeah, better language that captures more precisely what we want. Okay. Anything else on Fishaka for the moment? Okay. Then, Glacier Dam. This should be exciting, we can talk about scoping, and, you know, one reason it will be exciting is there are a large number of VIPs. Actually, let me just try to grab the MetaVIP link.

If people want to follow along that way. So, there are a large number of PFI'd EIPs. And the good news, for today is most of them are… entirely on the EL side, which makes our job a little bit easier on the CL side. And I tried to keep track, like, keep up with everything. We had the deadline today, so there were a lot of things. I think there's even a few more that are still in PRs, which, you know, just to be clear, I think that's fine. We can get those merged, you know, today, tomorrow, and I think those can still be in bounds. There's, yeah, a few things we need to do on the EIP editing side, just to actually get them in.

But, in any case, Yeah, so there's a number here of, EIPs on the agenda that we can cover today. And… Yeah, I think we're pretty much ready to get into it. I guess one more comment here. is, in terms of process, I think today, you know, we can just maybe touch on each one. And… If people are here and want to say a few words, that's great. If there's, like, other considerations we want to get into, you know, we can start that process. I… you know, given the timings here and the deadline being today, I'm not expecting people to, you know, like, we don't even necessarily have the full set until now, so… We can't really make decisions today, and…

Then what I would propose is, each client team, again, have a written proposal, kind of like we've done in the past, with their view of what should go in on the CL side, and have that by the next ACDC. So that would be two weeks from today, that's 13th November. And that should be… Hopefully a nice way to move forward, yeah, I'm expecting… Well, at least I'm hoping there's pretty, Pretty default, rough consensus, just, once everyone takes a look, and we move forward. So… I guess one question then for everyone here, does that sound okay timing-wise? Having something together in the next two weeks? And then we can take that input on the next ACDC and move forward there.

And, yeah, I'm hoping it should be a pretty smooth process on the CL side. Okay, yeah, I got a few thumbs up here. As we went. So, okay, so let's do that. And then… let's get into it. So… I'm just checking to make sure there aren't other comments here. I think I got them all, so… Yeah, I went down the list yesterday and just tried to pull out the CL ones. Also, yeah, if there's one I missed, please call it out. That was just an omission on my part, because, again, there's a very long list to go through. But I tried to pull out the things that have any seal bearing, so either are entirely in the seal layer,

Which I think they bifurcate pretty well. Maybe fossil is the one cross-layer thing that we still have to discuss. But yeah, so let's go. The first one would be 7688. This should be the SSZ EAP that introduces stable containers. We'd had, Pureeth as, like, this bigger bundle of features for, like, clients and, you know, different things in that domain that, I believe was proposed as the headliner, but was not selected. eTong came back and picked out a smaller subset to propose as a PFI EIP. So, we have this one. I don't know if Etan's on the call, or if anyone wants to speak to 7688. But this would be a good chance to do so.

Okay. Okay, and yeah, Justin's just calling out here. There is a specs PR on the seal side. Pr4630, link here in the chat if you want to take a look. So… Yeah, I think that's probably it for that today. But keep it in mind, this should be something that we reason about for, the scoping over the next two weeks. Okay. Next up, 8045. So, this EIP, essentially changes the way the proposal shuffling works, so that we exclude slash validators. Today, if you look at the specs, when you go to derive the proposer shuffling at a given point in time, it selects from the entire set of validators, and that could include slash validators. At the same time, we have a rule that slash validators cannot propose, and so this basically is a de facto missed slot.

And, you know, I think usually this isn't really an issue, because there just aren't that many slash validators, especially on mainnet, at a given point in time. This did, I believe, become more apparent on Halushki, for example, because there were many more slash validators there, and then what happens is, you know, the chain quality or, like, liveness kind of degrades, which is not nice, so… 8045, just has a small change to how the permitting shuffling works, to exclude slash validators. Pretty straightforward. I actually forget who… Barnabas, were you actually the author on this one? I feel like I remember that.

Barnabas Busa: I'm a co-author.

Alex Stokes: Okay. Well, do you or another co-author want to say anything? That's not just the overall.

Francesco D'Amato: Yeah, I mean, I think… it's pretty simply IP, you think you said pretty much everything. Yeah, the motivation came from Barnabas, which I think you pretty much already covered, and… Yeah, I think, basically. It's just something that used to work this way because, we didn't have proposed look ahead, and it would have caused problems to school slash validators. Now it doesn't. It's not a huge deal, like, it's, you know, it's clearly not the most important EIP, but it's also extremely simple. So maybe we might as well do it.

Alex Stokes: Okay, thanks. So, take a look at that one, again. This is, you know, famous last words, but I think it's… Essentially, literally a one-line change. So, pretty, pretty straightforward. Okay. Next up, we have 8061. This is an EIP that's, a little more involved than the last one, but not too much more. And it proposes to increase the churn limits. So, yeah, this one, we'll probably want to sit and think about a bit, So these turn limits have to do with entries and exits to the validator set. I think it also touches consolidations, right, Francesca?

Francesco D'Amato: Yeah, there's, like, kind of two separate churn limits, for consolidations and for the rest.

Alex Stokes: Okay, and so all of them would be increased with the CIP?

Francesco D'Amato: Yes. I mean, these are just… well, the numbers in the IP are… well, like, the IP is proposing to increase all of them. In principle, we could increase only the exits and entries, or only the consolidations, or anyway, do some… some… something, yeah, a combination of these things. But, like, I would propose to increase all of them, because I think there's reasons why we care about pretty much all of these numbers, and yeah.

Alex Stokes: Okay, cool. So yeah, so… It increases, all these trim limits. And, you know, for anyone listening who might not be that familiar, what this would mean practically is, yeah, it's faster for you to get into the sets, to exit the set, also to consolidate. Which sounds good, you know, I think that's a pretty strict UX win in a vacuum. Of course, there are always trade-offs, and what do we lose? Well, this would eat in 2 weeks of rotivity, that we have today, so… Again, I think this is a pretty straightforward change. In terms of the specs, but there are implications here for, yeah, essentially the security here with the switchability parameter, so… Something to take a look at, again, over the two weeks, and think a bit about.

Actually, yeah, Francesca, do you have a sense, I think, from what I remember… was it having the wheat? Like, basically, would it, like, double churn and then half-week subjectivity, or is it…

Francesco D'Amato: So it's, yeah, it's slightly more complicated, just because there's these two churns, and, with the numbers I put, which, again, are, like, preliminary, they're basically just some numbers that make the weak subjectivity period be around a week. And, yeah, with these numbers, you get something that's around a week, and the actual increases, like, in the assurance is. 4X for exits and activations, and 2X for consolidations. So it basically goes from, like, around 15 days to around a week, or, like, to be precise, 6 days. Which, to me, seems, like, quite reasonable. But yeah, of course, we can, like… I don't know, if we find, like, a number for the weak subject… subjectivity period that people

think makes sense, then we can sort of work back from there and figure out what the numbers can be from this perspective, in terms of the churns. And then, yeah, of course, there's these other considerations that people are mentioning in the chat. But, like, purely from, like, a weak subjectivity perspective, it's really easy to just work back from whatever period we're comfortable with to, which turns we should have.

Alex Stokes: Okay, yeah, and maybe just to refresh everyone, weak subjectivity… weak subjectivity. Number one is a mouthful to say. Number two, you know, the way to think about this is, how often do I need to come online as a node? And, you know, I think… A heuristic we'd probably all agree to is that, you know, if you are running a node, it's pretty much always online. If you're not online, that's when this will come into play. And, you know, let's say we go with the EIP, like Francisco was saying, the period comes down to, like, 6 days. That would mean that if I'm offline as a node for more than 6 days, I would need some piece of external information to know what, quote, the correct chain is, right?

An interesting thing here is, you know, we've had this notion from the very beginning of the beacon chain, and something we've kind of had more of since is this notion of checkpoint sync. So, you know, point being, there is, like, I think much better infrastructure for getting this information, to know what the corrupt chain is. And yeah, generally, I think it's, yeah, more… at least to me, I feel more comfortable shortening this period. Again, I don't… yeah, I don't have a view on the exact number, but… I think we can do this, again, given the benefits, which, again, would be much better stake in UX, which is something that comes up, quite a bit, so…

There is a little side discussion here. Ansgar, brings this up, okay, essentially touching issuance. I don't know, Ozgar, do you want to give a comment to this, just so people have it on their radars as they're considering the CIP?

Ansgar Dietrichs: Yeah, I mean, just that we've, in the last two years, had several conversations around the future of issuance on Ethereum. I think the situation is that many people have this belief that the pound issuance curve, Well, at some point, need adjustments, but at the same time, also, part of this experience was to say, hey, actually, there's many, many stakeholders, around staking, so we really have to be careful with this conversation and with changes, and basically, like. Have any… anything that would ever touch issuance be very, like… have a lot of, like, look-ahead time, where we would basically, like, introduce changes, With very long, kind of, lead times, longer than normal for changes. And as part of that, also, there was this adjustment of the,

the turn limit, or basically, like, this kind of this cap that, that was introduced, and part of the motivation was to say, okay, we just have a bound now on how quickly the situation around issuance can change, right? So the issuance, obviously, is a function of how many… how much ETH is staked in total, so the… the… the, basically, like, for exits, in a way, it really doesn't matter so much, because, yeah, that just gets us back to kind of issue… validation situation that we had in the past. Entries, basically, is the potential thing that can really start changing the situation quite a bit, and so… Yeah, one implication of the CRP that I personally would not like is that it basically… I would say it is almost in itself an issuance change, because it… or, like, at least it's changing the system that is kind of generally connected to issuance, and so I personally would

Already say that that should follow the rule of no, kind of, last-minute changes to, or, like, no kind of, like, short-term changes. But also, more, more, more, more concretely, it basically would mean that, if there was a shift in Environment where, basically, you know, you can imagine, like, many new entities that all want to stake. that between us seeing that the entry queue would be completely backed up, and us being able to, like, to make any changes to issuance, to react to that, there would no longer be enough time, right? So basically, it would mean that between the start of that backlog and the time that we could see 70, 80% staked, that there wouldn't even be necessarily a hard work anymore, because it could go so quick.

So, so I personally, would… would probably, consider at least having… having this ERP modified to not touch the… the entry, speed, and only modify the ABAS.

Alex Stokes: Okay. Yeah. I mean, I guess I'll just add a comment here. Personal take. I feel like if we were to look at the queue and see, oh, it's suddenly too big, and then try to transition some response, that would be, also a thorny thing to do. Because one, we'd have to, like, roll out a change pretty quickly, I think, you know, much faster than our historic hardcore cadence, and also, it's just, like… You know, you can ask the question, at what point does that change? You know, the guarantees people thought they had when they entered versus when they actually activate. But then…

Ansgar Dietrichs: authentic guidance that we have… sorry, I don't want to interrupt you, but, like, for example, with stakeholders like, Lido, we've talked a lot in the past, You know, because again, they obviously, like, just, like, an example of, also others, like, just mentioning them, because they're the biggest, maybe, example of people that have to make forward-looking decisions based on, based on, kind of, their emissions, and one thing we've always been saying is basically, like, hey, look. Normally, under normal conditions, kind of like an issuance change would probably be something we, like. A obviously would be up for the community anyway, but, like. from our side, we would recommend, from the time something like this is again introduced into the discussion, we would probably want to, like, have a year and a half, two years at least, between it being first proposed and it going live. The one circumstance in which that could have to be a bit faster would be specifically if

there's a big backlog of the entry queue. And so, basically, that's always the one thing that we point to at, like, is, like, the one kind of circumstance under which If you might have to act faster. But at least might have dried faster, still within reasonable speed, like, even today, like, with… it is actually quite slow for the inflow. And I think, again, that would just change now. with this, EIP, That would make me, if we were to accept it as is, that would make me, for example. probably start working on a concrete issue and change proposal for H-star, because I think otherwise it would no longer be responsible to have too much of a kind of time

whether the chain is that vulnerable to large changes in stake percentage. So, just wanted to flag it. Again, like, I think… And it would also not be the end of the world, but I think it would meaningfully change the dynamics around issuance.

Alex Stokes: Okay, yeah, that's a good… that's a good call-out. And yeah, maybe just to, like, play that back a bit. So, to be clear, this does not change the issuance curve, like, it does touch on the mechanics around issuance, like Ansvar was just pointing out. You know, this is not something, like, in the past, even in proof-of-work Ethereum, where we, like, quote, change the issuance. This does not do that. It does change mechanics around how quickly things can change within the current system, and then there are these second or even third-order effects, like Anzara was just saying, so… Point being is… For people today, as you go to look in CIP, again, over the next couple weeks, it might look like a pretty simple change, but there are, definitely, again, second-order effects to keep in mind.

Okay, I think that's enough for that one, and yeah, thank you everyone for the context there. Let's see what's next. Okay, yeah, a few more here, so… Anders had a comment, that he had. I think there were 3 different EIPs, I guess 2 now. And that's because Mikhail has another one, and this is touching on, yeah, a number of different things. So, at a high level. We've been thinking quite a bit about consolidations. And, you know, I will throw out this sort of, main, main desire or constraint, which is that we want to consolidate the validator set. If you look at adoption, so far, since Spectra, you know, it is actually… like, if you look at the adoption chart just in itself, it's trending up and right, which is cool.

But overall adoption's, you know, pretty low. There's a number of reasons for this, even as simple as, like, you know, I think there's not great tooling, and that's something we can, you know, very easily improve, very quickly. But then, once you start looking into this more deeply, there are a number of things we could think about, to make this better, and essentially, in some sense, incentivize consolidations, to set us up for things down the line, like single-slot finality, or other things that greatly benefit from a smaller validator set. So, that all being said, either Mikhail or Anders, if you'd like to speak Briefly, about your EIPs, that would be helpful.

Anders Elowsson: Yeah, I can, start, So there's two APs that essentially just make it such that, because we want to transition people from the skimming validators to the compounding validators. And so there are two AIPs that, because the skimming validators, the original ones, CO1s, they actually have benefits over the CO2 validators. Both when it comes to the skipping function, which they don't need to pay for the withdrawal, even though it imposes some load. on the protocol. So, the first one, EIP8062, just attaches a fee, then, to the sweep withdrawal accounting, roughly for the load that it imposes. And it's taken out as 0.25% of the withdrawal amount. And the idea, then, is that, That, that we make it…

Slightly more favorable to go over to the compounding validators and then consolidate them. And the second issue, and the benefit that the skimming validators have. Is that, they have, They have, on average, around 0.75… EATH of effective balance that is working to their yield that the compounding validators do not. So, a skimming validator is very capital efficient. All of the staked EATH is counting towards the effective balance, whereas a compounding validator Only, only, only because… because, you know, they… there's this high stress function, and they… they do not get, accounted for the balance until you… you… you go up onto the next band, and for this reason. You… you lose out on staking it, because you have

That is to say, 0.75E this. stake, counting towards, Your Honor, Your Honor. Awards. And so, this, this EIP, 8 to 68, has a neutral effective balance design. So that, that the compounding validators, have, on average, the balance… counting towards the effective balance, in ambient folk. That's also… there's also another issue with the current, effective balance calculation, is that you can withdraw down to… if you have a compounding validator, you can withdraw down to 32.75 ETH, for example. but account for 33 in effective balance. And so you can increase your yield by using a compounding validators. But not… Consolidating it into a big validator, you just use a small one.

We want to avoid that also, so 868. Justice this, this is true.

Alex Stokes: Okay, thanks. Yeah, your audio, the volumes seem to be oscillating a bit, But then, yeah, to play back at least what I understood from that, so the first EAP8062, this would basically… say that if you're a validator in the automatic, sweep with what I think we're still calling partial withdrawals today, it basically adds some, like, very small percentage fraction of fee. Basically, you just, like, would burn the extra ETH, And this is a small incentive to move to a consolidated validator, so that you don't have this behavior. The second one, I haven't had much time to digest. It sounds like it tweaks The balances work, and it gives some better properties to consolidation. I don't know if that was a fair summary, Anders.

Anders Elowsson: Exactly. The second one, it makes it such that you're essentially doing a rounding to the nearest integer when you compute your effective balance.

Alex Stokes: I'm gonna… And that's better for compounding validators, just given how the compounding actually works.

Anders Elowsson: Right now, they get the effective balance bump. They only bump up to, for example, if they reach 35.25 ETH, that's when they reach 35. So if they have, like, 35.1 ETH, they only get 34 ETH of effective balance.

Alex Stokes: Agree. Gotcha. So, okay, those two. Any questions? Otherwise, just put them on our stack. And if not, then, Mikael, I think you have the next one here. This was… oh yeah, so preventing consolidations as withdrawals. Yeah, there's a little bit of context here around this. Mikael, do you want to take it over?

Mikhail Kalinin: Yep. Okay. So… Yeah, BCIP prevents consolidations of withdrawals, as Alex said. Today there is a… the consolidation mechanism designed in a way that if the target… Target validator, after consolidation, gets the balance that exceeds the max effective balance. The advocacy will, will be withdrawn, basically, by this week. And We see that, these, let's call it a feature. This feature has been recently heavily exploited, because there is an imbalance between the exit and consolidation queues. So, yeah, it requires, of course, it requires 2,048 ETH validator, but yeah, that's,

Obviously possible for staking pools. And, yeah, of course, important to mention that consolidations were never meant to, because this way, consolidation short was never meant to be used as, As exit… as the exit churn. And, this CIP basically, It's a fix to this problem, and what it does, it just cancels the consolidation request if the target will The target effective balance will exceed the max effective balance. After consolidation. It also takes into account pending consolidations that are in the queue. Yeah, that's… that's what it is.

Alex Stokes: Cool. What's your sense of… how important this is to having in Amsterdam. Like… It seems like this is the nice to have, but it's not necessarily critical, or do you think it's, yeah, more important to go ahead and patch?

Mikhail Kalinin: Yeah, true, it's… yeah, I forgot to mention, which is also important, it's not a security issue, it's more kind of UX, problem. And, it also depends on how long do we want to, how long we want consolidations to, remain as a feature in the protocol. Because when we were introducing consolidations, one of the thoughts was that this is a temporal thing. Until we see, A good consolidation level. In the validator set. But, As, for me personally, it's an open question when we can, fabricate consolidations, so… Yeah, it's, it's, it's really a nice-to-have feature. It's not, it's not super important, there is no security issue with that, but it's also, it's also a quite simple change.

So, yeah, that's kind of… it's trade-offs, and yeah, I think… Just make a decision to have it or not.

Alex Stokes: Okay, great. Yeah, thanks for the overview. So, okay, there's that basket of three things that touches some of the mechanics here around, staking and the UX there. So, let's see, okay, I think we're good there, and the next thing would be cell-level deltas and PureDust. Raul wanted to say something here. And it…

Raúl Kripalani: That's a bitch.

Alex Stokes: Here is there's, you know, some changes that aren't necessarily in consensus, but definitely touch on things we want to do. to keep scaling bulbs, and definitely something to keep, in mind as we think about scoping. But yeah, we'll take it from here.

Raúl Kripalani: Yeah, so just to… hey, hey everybody, so just to kind of, like, guide the discussion, I have some materials here. They're very short, I just took the ability to share them. So, just wanted to give, first of all, a TLDR of what peer cell-level deltas are. They're a CL-side network optimization that eliminates the need to transmit redundant column information and data during the critical path, during the burstiest path. of, activity in the network. And it does so by leveraging partial blob data that's available in the EL blob pool. If you all remember, there was kind of, like, a discussion a few months ago around get blobs v3, and that method in the engine API, and that method powering the solution. Well, this is basically it, and we've been working hard towards it, and I just kind of, like, wanted to present the status of affairs and next steps here.

So… what nodes do is they construct poems by exchanging and reconciling cells with one another, and this is implemented as a gossip sub extension. And a gossip sub extension is basically a a piece of… a functionality that is negotiated between two parties when they establish a gossip… when they handshake on GossipSub. Which, is precisely what makes this solution, backwards compatible, there is no consensus impact, and it's deployable gradually in the network by different clients, different, different operators at different points in time, and, that's why it can be done XFORK. So, yeah, we're kind of, like, chatting about this in the context of Lamstam, but just kind of, like, to reiterate what Alex said, this is, like, the intention is to deploy this solution next work. So, the motivation, for this is that it allows us to unlock the next tranche of BPOs.

Going from the 21 max that we have right now in the schedule, all the way up to 72 blobs max, at least. There is a possibility that we can go even further with just this optimization, and kind of like some other minor optimizations that we're working with, with client implementers directly. We predict that the next bottleneck is gonna be the EL Blob Pool, and to kind of, like, deal with that, we submitted an EIP, for Glamstadam. It was just submitted yesterday, you might have not seen it yet, but it's titled Sparse Blob Pool. So, I'll post a set of links in a bit, in the chat so that you can start looking at that material as well.

So, the early results, and these are, like, caveat, massive caveat, these are… just from small dev nets, they are really promising. They're showing an average reduction of 10x in column traffic during propagation. Remember, during the burstiest part of this flood and the critical path. And this is extrapolating the current rate of public versus unseen blobs in the blob pool, right? So, there are some charts there, the… they look at it, like, a little bit… like, it doesn't seem like a 10x, but that's because the axes are actually, different orders of magnitude. The current status of implementation is that we've got a Prism prototype ready, and it's being reviewed by the team, so thanks a lot, Casey. And another shout-out to the Lighthouse team, who's already gotten started with the implementation, and the prototype. The gossip sub side of things are almost… are ready, I think, and Daniel is working on the client-side implementation of this.

So, in terms of BPO schedule, this is what we're thinking. The core notion here is, can we provide a smooth continuation of the current planned BPO scheduled by basically appending the next tranche which, here we're differentiating calling them BPO Plan and BPOnext. So, this could be a potential BPO schedule, and… and there are some dates there, I'll talk through them in a second. But basically the key… the key points here is that the… So, if we continue the schedule, then the next one would be BP03, the next work would be BP03. That could come around February 26th? And, it would just be a small parameter bump to ensure that everything looks nominal under… under… with sellable deltas. From there on, the idea would be, to spike, to increase max further, so that we can see what the network, how the network is performing, and we can analyze how the network is performing with burst year…

spikes, but not sustained spikes. And then from there onwards, we would just start doing constant, if everything looks good, we will start doing a constant, increment of, like, of what you see there is, like, 32, 48, 48, 64, and 64, 72. Basically on, every two weeks, there would be a BPO, fork here. Now, this is, just a very indicative, speculative timeline, of how this could progress. So, we're currently at the implementation stage, as I said. We are intending to perform… to run larger DevNets, and this is… we're using… we're helping… we're getting a ton of help from… from Sunnyside Labs for that. That's currently in progress. The next step would be interoping with Lighthouse, and through that, we'll end up… we'll continue iterating on the design, and specifically closing some of the open points around early, or eager pushes from, for example, relays, or no

precisely which blobs are private and which have been publicly available? Can those relays just push? The delta that is necessary for the network to reconcile, what assumptions can we make about the network-wide availability of blobs in the blob pool, and things like that. as what we'll be, I think, polishing and kind of, like, fine-tuning. And then there are some… some other technical questions about the schema around, do we include the block headers or not, within… within the partial messages. Now, what I wanted to call out here is, by November, we expect to have a final version of the spec that is fully interoperable, that is seen, like. full interoperability, and at that point, I think the idea would be for the Get Blobs v3 engine API operation to be shipped in all execution clients in preparation for this, and this basically means a rehash of

I think all ELs actually had a PR that they, that they closed down when we de-scoped this one for Saga, so that would be rehashing that PR and merging it. And then, by November, I would like to see the rest of the implementations, members take one Lodestar beginning to implement, and by December, if we can have them already. And such that we start getting them in production-grade state, and we start battle testing them with larger and larger and larger testnets. I would like to kind of, like, walk into the winter holidays with a BPOnext schedule proposed, that would be… that would be amazing. And then when we're back, we… I would like us to… like, the idea would be to commit to that schedule, and to make the releases, and to kind of, like, start the… the more formal… the initial releases, and start the more formal testnet

journey up until Maynet. Some of these dates might shift. As I said, this is very indicative, but, like, the intention of this is basically to align us all against a common timeline, and I'm very happy to take feedback and input and refine this further based on feasibility and other workloads. That, that client teams are also, engaging in. Cool. So, basically, what's next? We are… the next steps, as I said, we're running larger testnets and conducting battle testing, conducting interrupt tests, as Lighthouse also gets ready, against the Prism prototype, and then the asks for implementers here would be for the CL implementers. Please, if you haven't engaged with this work yet, then please review, comment on the specs, and start planning implementation.

I'll share these materials after, after, after the call today, so you, so you can use them as a reference. And, and yeah, and then for EL implementers, as I said, this is… minimal impact to the EL, practically zero impact if it wasn't for GetBloxv3, so… and for which most of… most of ELs already have a PR, so, get ready to rehatch that PR, essentially. And… Yeah, so I'm very happy to take questions or thoughts, ideas, anything. Also happy to discuss off-end. Thanks.

Alex Stokes: Thank you. Yeah, that was a great overview. And… yeah. I think I'd just remind everyone that the general theme of Amsterdam, and essentially, you know. The present time and the foreseeable future is scaling. That might have been a lot from the presentation that we just saw from Earl, but again, it all goes towards scaling, scaling, so… critical work, and something to keep in mind. Especially if you look at, the other PSI EIPs, and you're like, oh, you know, there's not this much, you know, these are, like, one-line changes, we'll just put this here and here. Keep in mind, you know, we very much also want to keep doing, the work Raul was just pointing to, so…

that's, I think, gonna have impacts, for the other EIPs we select for Amsterdam. Any questions? From what Raul said. Okay, one thing, we can do offline roll is just get that information you just shared, just somewhere, I think public. It might be in some place, but yeah, we'll just get it somewhere just so people can refer to it.

Raúl Kripalani: Yeah, I'll follow up on that.

Alex Stokes: Otherwise, cool. Yeah, that was… that was great. Thanks for the overview. Okay. Now, there's one question here. Maybe 2. Okay, so, like, clients asking, do seals feel good about another 3 BPOs while finishing glamps are down? My general comment to this is kind of what I was just getting at, is that, you know, I think we can scope ClapterDam in a way where this is definitely doable. If we aren't thinking about these non-consensus changes on the networking layer, and just put in every last, you know, CL EIP into Glenster Dam, that's where things could start to be a little… Tight, but… Yeah, I think there's certainly a path here, so that's something we should just reason about as we go to scope.

I don't know if any other SEAL team wants to chime in. To like Clan's question? Okay, Enrico here's asking, well, partial message extension… okay, it looks like you guys are handling that in the chat. Yeah, just chime in if you'd want to speak up live. And there's still a conversation going around the staking stuff. I'll just let that be for now. Okay. Matt says, I'd like to hear from the actual CL teams. Anyone want to chime in? I think folks might need some time to digest. So, you know, let's… let's just take this to the next call.

Okay, we did get it, I think we'll be fine, from Kini. Okay, so yeah, again, I think today, I just want to surface, you know, all the options with the different, EIPs. And get us thinking about, scoping. So, the… idea then is that we have another two weeks to actually form opinions, so we can hash it out on next ACDC, so… I think we're good for there for now. And… let me see what's next on the agenda. Okay, so the last one here is, Fossil, which is, you know, a little bit special than the others, which is why I kind of put it last here. So, yeah, EAP7805. This one was CFI'd, essentially because it was not selected as a headliner for Amsterdam.

But, yeah, the decision made at the time was to CFI it and just kind of put it to the side. So this is another one that, we can have on the table as we go to scope the fork. And… We've said quite a bit about it already, Let's see… I'm trying to see if there are any authors here on the call.

soispoke: Yep.

Alex Stokes: If anyone would like to say something. Oh yeah, go ahead.

soispoke: Yeah, I'm… yeah, it's gonna be short, because I do think a lot of, things have been said around Fossil, and yeah, I… yeah, things haven't, like, drastically changed, I guess, and… It still seems like most people, like, amongst the community, but also core devs and researchers, like, agree about the importance of, like, shipping fossil at some point. Because, you know, it does basically allow you to keep scaling without, like, hurting some of the fundamental properties we really care about. But yeah, most of the disagreements, I guess, seem to be focused around when false should be shipped, and so, you know, there are concerns around false scope and… If the Roman upgrades needing to ship on a regular cadence, which I think is so important, people call that fork discipline, I guess.

And so there, like, given the readiness of Fossil, that's now, you know, having interrupt between 2 EL clients and 4 CL clients. I don't know, there seems to be rough agreement around Fossil, maybe realistically adding, like, a two-month delay to Glamsterdam timelines, but of course, it's very, very hard to tell in advance. And that being said, yeah, I think one aspect of the decision that wasn't really mentioned explicitly before is, quote-unquote, the shipping environment. And so, by that I mean, like. I don't know, governance, political landscape, institutional adoption, like, state TTFs and stuff like this, and how it might affect, like, proposals like, like, like Forsol, but also, you know. privacy ones or issuance CIPs that are also, like, sort of, like, touched by these considerations.

in opposition to, like, I don't know, like, scaling EIPs, or… or shorter slots, or whatever, that are not just, like, super affected by it, I guess. And, yeah, here I think the equation is, like, actually quite simple. It's like, either you think there is both a very, very high probability of fossil shipping in a later fork. That's… yeah, that's all assuming you like Fossil and you want it shipped at some point. So yeah, either you think high probability of Fossil shipping in a later fork, and a very high probability of the shipping environment, let's say, staying as friendly as it is today. By friendly, I mean, yeah, it includes, like, strong support from the community,

And there is momentum behind it, you know, you see even, like, builders being pro-fossil. There's actually not much censorship on the network right now, and there is a sort of, like, friendly political landscape, that looks generally favorable to these upgrades. And in that case, like, if you think that those… both of those probabilities are very high, I think, like, yeah, you might just favor, like, shipping cadence and process, and decide against including fossil in Amsterdam. But the alternative, I guess, is, like, if you think shipping foresaw will only be increasingly difficult over time, and basically the more we wait, the more we expose the protocol to, you know, censorship, or, like. bad things we don't want to see on the network, and maybe, like, pressure from parties that will see risks in allowing AIPs like Fossil to be included in future forks.

then I think you might lean in favor of including it, just, like, as soon as possible, which means in Amsterdam. And so I think, yeah, regardless of what side people end up on, I think it's… nice to at least include this dimension when forming an opinion for sole inclusion, because I do think it's an important decision to make for Ethereum. And, yeah, I wanted to end with a small anecdote. I was checking out the new website by, let's called institutions.ethereum.org yesterday. And there are… Ethereum was described as, like, a network with no single point of failure, no central coordinator, no pause button, and resilient to geopolitical, regulatory, and infrastructural level risks. I think, yeah, I thought that was quite well put, but I guess my personal opinion is that I think we need to back those claims up a bit more.

Alex Stokes: Okay, thank you. Yeah, that was a nice overview. And… Yeah, I mean, I think just to maybe summarize that a bit, I think Anskar put it well here in the chat, that, yeah, there's, you know, kind of this trade-off to make between On the one hand, like, so I spoke was saying, you know, we want to, you know, not add too much uncertainty to constrained timelines. At the same time, there are… interesting second-order implications to this EIP, and EIPs like it. So, something to think about. I think that's… Perhaps enough on that for the moment. Would anyone like to add anything? Okay. So, let's see, I think these were all the CL, not headliner, PFID IPs.

That we had. Or, yeah, at least non-headlinear. EIPs, regardless of inclusion status. And that should give us a good overview. Again, thank you everyone who, just engaged and gave us, you know, overviews of the different EIPs. there's, you know, it does feel like there's actually quite a bit here once we get into it, even if, you know, on paper it's just a small number of EIPs. The EL side of this will be fun, as a tangential comment, but… Either way, yeah, so that should be a good overview. And there's a few more things I wanted to get to today, so… Okay, one clarification, because, yeah, AP Kotap, brought this up. So, I'll grab a link to this comment here. While I was proposing, we have, written opinions two weeks from now, and I said we would move these things to SFI.

I should be more precise, because, yeah, how we generally do this is that we would CFI things, and then, kind of have this lockstep process where… The things that are on DevNets right now are SFI'd, everything else would be CFI'd, and only once we're ready to add another EIP to the DevNets would we move from CFI to SFI. And, you know, we've kind of added this discipline, let's say, over the last couple cycles, and it's really helpful just to keep, you know, things kind of focused and organized. Otherwise, we'll kind of just end up biting off more than we can chew. Which we don't want to do, so… What that would mean then, precisely, is that on the next call, you know, we will…

Come back to the scoping discussion and try to make decisions on what to pre-ify. You know, just so it's clear, if we decide to not include fossil, then we would take it out of the CFI set print out, but then the plan then would be to have the CFI set determined, on the next ACDC, Again, at least on the CL side. And then, we'd keep EPBS SFI as is, and keep moving forward. And then from there, we'd have the clan stream scope settled. we keep moving forward, you know, as we get through things on DevNets, we'd start with the SFI EIPs on DevNets, and then, yeah, start moving EIPs one by one, as we're ready for those. So…

Yeah, thanks for the shoutout there. A.B. Kota. And… that should be good there. I think that's all I wanted to say. on that. There's a few H-star things to cover before we wrap up, but before we do that, any other Glamsterdam comments? Anything around scoping, or the EIPs, or anything else. Okay. Then we'll turn to H-star. The main thing for H-star is just to pick the name. And… yeah, let's look at that now. So… There's this informal poll here. That, if anything, is great for signaling. Let's see if I can grab a link… there we go, to just the full… So if you take a look, at this here.

There's a number of proposals, these should all be stars that start with H, which is our schema. And the leading proposal right now, it's kind of a toss-up between HECA or Alvedios. Heca is the leading candidate. And… yeah, I think we should just go ahead and pick one. And following the poll, let's just go with HECA. Everyone okay with that? Okay, God, it works for me. A. Bikotop was nice to put some possible portmanteaus here, you know, so we have the seal and eel names. On the EL, this is the Bogota fork that we would be discussing, so Hecca and Bogota could perhaps be HECTA. Hogota, I don't know, there's some options here that we can, see what sticks.

But… In terms of today, we'd move forward with HECA, and that would be H-star, and we can finally have a name, and stop calling it H-star. The most common hair is funny, heck of yes. Okay, cool. So let's go ahead and do HECA. And, yeah, we'll just see. People will come in with portmanteaus, and one of them will invariably stick, and we'll go with that. Cool. So, okay, we've covered a lot today. Let me just scan the agenda and make sure there's nothing else we need to get to. H star name… Okay. I think we're pretty good there. Oh, okay, there was a call for a mascot. Did we ever have a mascot for Clarence Trident?

If not, we can, discuss this on Discord or somewhere, but yeah, there's a link if you want to take a look there. I'm not sure what it is. But it's something to think about if you want to put in a proposal for the mascot. Okay. Otherwise, I think that's it for today. Any closing thoughts or comments? Okay, if not, thank you all. Yeah, so… Let's just quickly summarize. We have mainnet for Forsaka locked in. That's big. Again, congrats, everyone, getting this point, and let's see it through to the end. We covered a bunch of things on Amsterdam, so, yeah, again… You know, your homework here is to think about scoping.

You know, including all the PFI DIPs, thinking about, also this work with, PureDOS and blob scaling iterations, that we would also want to schedule, even if they're, you know, export in the sense of not waiting until Amsterdam, but we still want to have bandwidth for them. Then also cross-layer IPs, which I think Fossil's really the only cross-layer one, but then, you know, we'll probably want to be mindful of the EL side when thinking about that. In terms of scoping. And, yeah, then we'll move ahead with HECA as a name for H-star. Okay. That should be it for the day, and yeah, thanks everyone. I'll see you next time. Okay. Goodbye.

Ansgar Dietrichs: Third one.

Mikhail Kalinin: Bye, everyone.

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