stokes:Okay, thanks, everyone. Welcome to ACDC number 168.
Transcript
stokes:This is issue 1772 in the PM repo.
stokes:And…
stokes: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.
stokes:And then we can transition into Glamsterdam and discuss a number of EIPs there to continue scoping that fork.
stokes:So… Let's go ahead and get into it.
stokes: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.
stokes: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.
Parithosh Jayanthi: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.
Parithosh Jayanthi:The hoodie data is a bit more interesting. We do have a better distribution of,
Parithosh Jayanthi: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,
Parithosh Jayanthi: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…
Parithosh Jayanthi:festivalista.
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.
stokes:I guess it'd be good to also…
stokes:Yeah, at least explore if we could have a static test for this. I'm not sure if that was…
stokes: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,
Parithosh Jayanthi: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…
Parithosh Jayanthi:You want to speak, PK?
pk910:Nothing really to add there, yeah.
stokes:Okay. That works then. Cool, okay, well, nice find. And yeah, it seems like they already have it patched, so…
stokes:That's good. Okay, otherwise, yeah, it looks like things have been going pretty well.
stokes:Anything else on the forks?
stokes:Or more generally on Fusaka.
stokes:If not, I think we can go ahead and discuss mainnet dates.
stokes:So… excuse me.
stokes:So, yeah, on the last ACDC, I wanted to start this ball rolling, just so that, yeah, we could basically move ahead today.
stokes:Because the proposal would be following, this original dark, doc from Barnabas that… here, I'll grab this link…
stokes: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.
stokes:Along with that, there's dates for the BP01 on Maynet, that would be on December 9th.
stokes:And BPO2, that would be January 7th of next year.
stokes:So…
stokes: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.
stokes: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.
stokes:So, I'd suggest we do that now.
stokes: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
stokes:Everything we need to do there.
stokes:Anya?
Manu:Yeah, hi. So the rings are…
Manu:who did fork, so some user reported some bugs we, for some reason, didn't see on Holesky, or Sepolia, or testnets, or DevNets.
Manu:Rough.
Manu:Some of them are, fixed, or…
Manu:Are going to be fixed, and for at least one bug, we don't have the root cause yet.
Manu:For example, this bug is, yes, is, after a few hours.
Manu:Prism Nodes tends to… kick out.
Manu:non-present peers, and so after a few hours, the prism has only prism pairs.
Manu:We don't have a fix yet, and for that reason, it's very likely we cannot…
Manu:release on, next Monday.
stokes:Okay Hmm.
stokes:Okay, maybe we'll circle back to that. Is everyone else okay with, these dates?
Manu:I'm not saying we should, we should delay the mainnet, but I'm just saying that it's unlikely we release on Monday.
stokes:Yeah.
stokes:Yeah, which is maybe okay.
stokes:Like, especially if we get something, you know, at some point next week, I think that still is enough time for people.
stokes:Okay. Would you be okay, then, if we went ahead with these dates, that we have as is, and…
stokes:Yeah, I mean, worst case then, like, something…
stokes:Would become a deeper issue than we expect, and then we would need to adjust, which we could do.
stokes:There just might be some thrash with everyone else trying to get ready.
Manu: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.
stokes:Yeah, sounds like it'd only really become apparent on a hoodie.
stokes:Which is, you know, interesting. I think Hoodie has a much more realistic, node distribution than the other testnuts, so…
stokes:Okay.
stokes: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.
Manu:Yeah, I agree with Justin about keeping mandate dates and delay release from prison.
stokes:Copp.
stokes:Okay, then in that case, let's see… I think, let's see, Nimbus…
stokes:I'm not sure if anyone from Nimbus is here.
stokes:Or Grand Dean, if they're around.
stokes:Okay, well, as far as I know, they wouldn't have any issues with this. So, let's go ahead and do that.
stokes:And… yeah, Prism team, we'll just wait for your release as soon as we can get it.
stokes: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.
stokes:That will have all this information.
stokes:And, yeah, one more note on that,
stokes: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.
stokes:And… then we should be good there.
stokes:And otherwise…
stokes: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.
stokes:This is a really cool fork.
stokes:the people I've talked to in the community are very excited about it, and yeah, it's a really big deal, so…
stokes:Super exciting.
stokes:And yeah, let's just then focus this next month on getting a safe upgrade to Mainnet.
stokes:Cool.
stokes:Okay, thanks everyone for the updates there.
stokes:I did want to circle back to this one last thing for Fusaka.
stokes: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.
stokes:He essentially proposes to change the language such that, we only need at least one testnet, and
stokes:There's some discussion on the PR if you want to check this out.
stokes:I think the feedback is a bit mixed, and I kind of tend to agree, like.
stokes: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.
stokes:Again, of course, you know, I think the…
stokes: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.
stokes:Yeah, so, in any case, I don't know if anyone wants to say anything else about this, at the moment.
stokes: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…
Ben Adams:Waiting for the testnet to set a date, but…
Ben Adams:The distance from the testnet going live to when the mainnet date is.
Ben Adams:If you say to me.
Ben Adams:That period between the two, rather than…
Ben Adams:When we decide on the date.
stokes:Mmm… Perhaps. So, I mean, the thing we definitely want is one month between the date and Maynet.
stokes:And… I believe the intent here is just to have the ability to…
stokes:You know, essentially all agree on what the date would be, even if the testnets haven't forked.
stokes:That way we can move things forward, kind of like we were trying to do this time, where, you know,
stokes:Especially given the timing here, where, like, presumably we'd have releases out on Monday, or, again, sometime next week.
stokes: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.
stokes: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.
stokes:But yeah, so…
stokes: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…
stokes:Yeah, better language that captures more precisely what we want.
stokes:Okay.
stokes:Anything else on Fishaka for the moment?
stokes:Okay.
stokes: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.
stokes:If people want to follow along that way.
stokes:So, there are a large number of PFI'd EIPs.
stokes:And the good news, for today is most of them are…
stokes:entirely on the EL side, which makes our job a little bit easier on the CL side.
stokes: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.
stokes:We can get those merged, you know, today, tomorrow, and I think those can still be in bounds.
stokes:There's, yeah, a few things we need to do on the EIP editing side, just to actually get them in.
stokes:But, in any case,
stokes:Yeah, so there's a number here of,
stokes:EIPs on the agenda that we can cover today.
stokes:And… Yeah, I think we're pretty much ready to get into it. I guess one more comment here.
stokes:is, in terms of process, I think today, you know, we can just maybe touch on each one.
stokes:And…
stokes: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.
stokes: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…
stokes:We can't really make decisions today, and…
stokes: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.
stokes:And that should be… Hopefully a nice way to move forward, yeah, I'm expecting…
stokes:Well, at least I'm hoping there's pretty,
stokes:Pretty default, rough consensus, just, once everyone takes a look, and we move forward.
stokes:So…
stokes:I guess one question then for everyone here, does that sound okay timing-wise? Having something together in the next two weeks?
stokes:And then we can take that input on the next ACDC and move forward there.
stokes:And, yeah, I'm hoping it should be a pretty smooth process on the CL side.
stokes:Okay, yeah, I got a few thumbs up here.
stokes:As we went. So, okay, so let's do that.
stokes:And then… let's get into it. So…
stokes:I'm just checking to make sure there aren't other comments here.
stokes:I think I got them all, so…
stokes: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.
stokes:But I tried to pull out the things that have any seal bearing, so either are entirely in the seal layer,
stokes:Which I think they bifurcate pretty well. Maybe fossil is the one cross-layer thing that we still have to discuss.
stokes:But yeah, so let's go. The first one would be 7688. This should be the SSZ EAP that introduces stable containers.
stokes: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.
stokes:eTong came back and picked out a smaller subset to propose as a PFI EIP. So, we have this one.
stokes:I don't know if Etan's on the call, or if anyone wants to speak to 7688.
stokes:But this would be a good chance to do so.
stokes:Okay.
stokes:Okay, and yeah, Justin's just calling out here. There is a specs PR on the seal side.
stokes:Pr4630, link here in the chat if you want to take a look. So…
stokes:Yeah, I think that's probably it for that today.
stokes:But keep it in mind, this should be something that we reason about for, the scoping over the next two weeks.
stokes:Okay.
stokes:Next up, 8045. So, this EIP, essentially changes the way the proposal shuffling works, so that we exclude slash validators.
stokes: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.
stokes:At the same time, we have a rule that slash validators cannot propose, and so this basically is a de facto missed slot.
stokes: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.
stokes: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…
stokes:8045, just has a small change to how the permitting shuffling works, to exclude slash validators. Pretty straightforward.
stokes:I actually forget who… Barnabas, were you actually the author on this one?
stokes:I feel like I remember that.
Barnabas:I'm a co-author.
stokes:Okay.
stokes:Well, do you or another co-author want to say anything?
stokes:That's not just the overall.
Francesco:Yeah, I mean, I think…
Francesco: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…
Francesco:Yeah, I think, basically.
Francesco: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.
Francesco:So maybe we might as well do it.
stokes:Okay, thanks.
stokes:So, take a look at that one, again.
stokes:This is, you know, famous last words, but I think it's… Essentially, literally a one-line change.
stokes:So, pretty, pretty straightforward.
stokes:Okay.
stokes:Next up, we have 8061. This is an EIP that's, a little more involved than the last one, but not too much more.
stokes:And it proposes to increase the churn limits.
stokes:So, yeah, this one, we'll probably want to sit and think about a bit,
stokes:So these turn limits have to do with entries and exits to the validator set. I think it also touches consolidations, right, Francesca?
Francesco:Yeah, there's, like, kind of two separate churn limits, for consolidations and for the rest.
stokes:Okay, and so all of them would be increased with the CIP?
Francesco: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.
Francesco: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.
stokes:Okay, cool. So yeah, so… It increases, all these trim limits.
stokes: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.
stokes: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…
stokes:Again, I think this is a pretty straightforward change.
stokes:In terms of the specs, but there are implications here for, yeah, essentially the security here with the switchability parameter, so…
stokes:Something to take a look at, again, over the two weeks, and think a bit about.
stokes:Actually, yeah, Francesca, do you have a sense, I think, from what I remember…
stokes:was it having the wheat? Like, basically, would it, like, double churn and then half-week subjectivity, or is it…
Francesco: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,
Francesco: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.
Francesco: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.
Francesco: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
Francesco: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.
Francesco: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.
stokes:Okay, yeah, and maybe just to refresh everyone, weak subjectivity…
stokes: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…
stokes: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.
stokes: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?
stokes: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.
stokes:So, you know, point being, there is, like, I think much better infrastructure for getting this information, to know what the corrupt chain is.
stokes:And yeah, generally, I think it's, yeah, more…
stokes: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…
stokes: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…
stokes:There is a little side discussion here. Ansgar, brings this up, okay, essentially touching issuance.
stokes: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,
Ansgar Dietrichs: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.
Ansgar Dietrichs: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,
Ansgar Dietrichs:With very long, kind of, lead times, longer than normal for changes.
Ansgar Dietrichs:And as part of that, also, there was this adjustment of the,
Ansgar Dietrichs: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
Ansgar Dietrichs: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,
Ansgar Dietrichs: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…
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Ansgar Dietrichs:But also, more, more, more, more concretely, it basically would mean that, if there was a shift in
Ansgar Dietrichs:Environment where, basically, you know, you can imagine, like, many new entities that all want to stake.
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Ansgar Dietrichs:So, so I personally, would… would probably, consider at least having… having this ERP modified to not touch the…
Ansgar Dietrichs:the entry, speed, and only modify the ABAS.
stokes:Okay. Yeah.
stokes: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.
stokes: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…
stokes:You know, you can ask the question, at what point does that change?
stokes:You know, the guarantees people thought they had when they entered versus when they actually activate.
stokes: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,
Ansgar Dietrichs: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.
Ansgar Dietrichs:Normally, under normal conditions, kind of like an issuance change would probably be something we, like.
Ansgar Dietrichs:A obviously would be up for the community anyway, but, like.
Ansgar Dietrichs: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
Ansgar Dietrichs: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
Ansgar Dietrichs:If you might have to act faster.
Ansgar Dietrichs:But at least might have dried faster, still within reasonable speed, like, even today, like, with…
Ansgar Dietrichs:it is actually quite slow for the inflow. And I think, again, that would just change now.
Ansgar Dietrichs:with this, EIP,
Ansgar Dietrichs:That would make me, if we were to accept it as is, that would make me, for example.
Ansgar Dietrichs: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
Ansgar Dietrichs:whether the chain is that vulnerable to large changes in stake percentage. So, just wanted to flag it. Again, like, I think…
Ansgar Dietrichs:And it would also not be the end of the world, but I think it would meaningfully change the dynamics around issuance.
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.
stokes: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…
stokes:Point being is…
stokes: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.
stokes:Okay, I think that's enough for that one, and yeah, thank you everyone for the context there.
stokes:Let's see what's next. Okay, yeah, a few more here, so…
stokes:Anders had a comment, that he had. I think there were 3 different EIPs, I guess 2 now.
stokes:And that's because Mikhail has another one, and this is touching on, yeah, a number of different things. So, at a high level.
stokes:We've been thinking quite a bit about consolidations.
stokes: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.
stokes: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.
stokes:But overall adoption's, you know, pretty low.
stokes: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.
stokes: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.
stokes:So, that all being said, either Mikhail or Anders, if you'd like to speak
stokes:Briefly, about your EIPs, that would be helpful.
Anders Elowsson:Yeah, I can, start,
Anders Elowsson: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.
Anders Elowsson:And so there are two AIPs that, because the skimming validators, the original ones, CO1s, they actually have benefits over the CO2 validators.
Anders Elowsson:Both when it comes to the skipping function, which they don't need to pay for the withdrawal, even though it imposes some load.
Anders Elowsson:on the protocol.
Anders Elowsson:So, the first one, EIP8062, just attaches a fee, then, to the sweep withdrawal accounting, roughly for the load that it imposes.
Anders Elowsson:And it's taken out as 0.25% of the withdrawal amount.
Anders Elowsson:And the idea, then, is that,
Anders Elowsson:That, that we make it…
Anders Elowsson:Slightly more favorable to go over to the compounding validators and then consolidate them.
Anders Elowsson:And the second issue, and the benefit that the skimming validators have.
Anders Elowsson:Is that, they have,
Anders Elowsson:They have, on average, around 0.75…
Anders Elowsson: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
Anders Elowsson: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.
Anders Elowsson:You… you lose out on staking it, because you have
Anders Elowsson:That is to say, 0.75E this.
Anders Elowsson:stake, counting towards, Your Honor, Your Honor. Awards.
Anders Elowsson:And so, this, this EIP, 8 to 68, has a neutral effective balance design.
Anders Elowsson:So that, that the compounding validators, have, on average, the balance…
Anders Elowsson:counting towards the effective balance, in ambient folk.
Anders Elowsson: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.
Anders Elowsson:but account for 33 in effective balance. And so you can increase your yield by using a compounding validators.
Anders Elowsson:But not… Consolidating it into a big validator, you just use a small one.
Anders Elowsson:We want to avoid that also, so 868.
Anders Elowsson:Justice this, this is true.
stokes:Okay, thanks. Yeah, your audio, the volumes seem to be oscillating a bit,
stokes:But then, yeah, to play back at least what I understood from that, so the first EAP8062, this would basically…
stokes: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.
stokes:Basically, you just, like, would burn the extra ETH,
stokes:And this is a small incentive to move to a consolidated validator, so that you don't have this behavior.
stokes:The second one, I haven't had much time to digest. It sounds like it tweaks
stokes:The balances work, and it gives some better properties to consolidation.
stokes: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.
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.
Anders Elowsson:So if they have, like, 35.1 ETH, they only get 34 ETH of effective balance.
stokes:Agree.
stokes:Gotcha. So, okay, those two. Any questions?
stokes:Otherwise, just put them on our stack.
stokes:And if not, then, Mikael, I think you have the next one here. This was… oh yeah, so preventing consolidations as withdrawals.
stokes:Yeah, there's a little bit of context here around this. Mikael, do you want to take it over?
Mikhail Kalinin:Yep. Okay.
Mikhail Kalinin:So… Yeah, BCIP prevents consolidations of withdrawals, as Alex said.
Mikhail Kalinin:Today there is a… the consolidation mechanism designed in a way that if the target…
Mikhail Kalinin:Target validator, after consolidation, gets the balance that exceeds the max effective balance.
Mikhail Kalinin:The advocacy will, will be withdrawn, basically, by this week.
Mikhail Kalinin:And We see that, these,
Mikhail Kalinin:let's call it a feature. This feature has been recently heavily exploited, because there is an imbalance between the exit and consolidation queues.
Mikhail Kalinin:So, yeah, it requires, of course, it requires 2,048 ETH validator, but yeah, that's,
Mikhail Kalinin:Obviously possible for staking pools.
Mikhail Kalinin: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,
Mikhail Kalinin:As exit… as the exit churn.
Mikhail Kalinin:And, this CIP basically,
Mikhail Kalinin:It's a fix to this problem, and what it does, it just cancels the consolidation request if the target will
Mikhail Kalinin:The target effective balance will exceed the max effective balance.
Mikhail Kalinin:After consolidation. It also takes into account pending consolidations that are in the queue.
Mikhail Kalinin:Yeah, that's… that's what it is.
stokes:Cool.
stokes:What's your sense of… how important this is to having in Amsterdam. Like…
stokes: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,
Mikhail Kalinin:remain as a feature in the protocol. Because when we were introducing consolidations, one of the thoughts was that this is a temporal thing.
Mikhail Kalinin:Until we see, A good consolidation level.
Mikhail Kalinin:In the validator set.
Mikhail Kalinin:But, As, for me personally, it's an open question when we can, fabricate consolidations, so…
Mikhail Kalinin: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.
Mikhail Kalinin:So, yeah, that's kind of… it's trade-offs, and yeah, I think…
Mikhail Kalinin:Just make a decision to have it or not.
stokes:Okay, great. Yeah, thanks for the overview.
stokes:So, okay, there's that basket of three things that touches some of the mechanics here around, staking and the UX there.
stokes: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.
stokes:And it…
Raúl Kripalani:That's a bitch.
stokes:Here is there's, you know, some changes that aren't necessarily in consensus, but definitely touch on things we want to do.
stokes: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.
Raúl Kripalani: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.
Raúl Kripalani:So…
Raúl Kripalani: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
Raúl Kripalani:a piece of… a functionality that is negotiated between two parties when they establish a gossip… when they handshake on GossipSub.
Raúl Kripalani: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.
Raúl Kripalani: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.
Raúl Kripalani: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.
Raúl Kripalani: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.
Raúl Kripalani:So, the early results, and these are, like, caveat, massive caveat, these are…
Raúl Kripalani: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.
Raúl Kripalani: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.
Raúl Kripalani: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.
Raúl Kripalani: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
Raúl Kripalani: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…
Raúl Kripalani: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?
Raúl Kripalani:And, it would just be a small parameter bump to ensure that everything looks nominal under… under…
Raúl Kripalani: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…
Raúl Kripalani:spikes, but not sustained spikes. And then from there onwards, we would just
Raúl Kripalani: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.
Raúl Kripalani:Now, this is, just a very indicative, speculative timeline, of how this could progress.
Raúl Kripalani: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.
Raúl Kripalani: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
Raúl Kripalani:precisely which blobs are private and which have been publicly available? Can those relays just push?
Raúl Kripalani: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.
Raúl Kripalani: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.
Raúl Kripalani: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.
Raúl Kripalani: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
Raúl Kripalani: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.
Raúl Kripalani: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.
Raúl Kripalani: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
Raúl Kripalani: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
Raúl Kripalani: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.
Raúl Kripalani:That, that client teams are also, engaging in.
Raúl Kripalani: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.
Raúl Kripalani: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…
Raúl Kripalani: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…
Raúl Kripalani:Yeah, so I'm very happy to take questions or thoughts, ideas, anything. Also happy to discuss off-end.
Raúl Kripalani:Thanks.
stokes:Thank you. Yeah, that was a great overview.
stokes:And… yeah. I think I'd just remind everyone that the general theme of Amsterdam, and essentially, you know.
stokes:The present time and the foreseeable future is scaling.
stokes: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.
stokes: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.
stokes:Keep in mind, you know, we very much also want to keep doing, the work Raul was just pointing to, so…
stokes:that's, I think, gonna have impacts, for the other EIPs we select for Amsterdam.
stokes:Any questions?
stokes:From what Raul said.
stokes:Okay, one thing, we can do offline roll is just get that information you just shared, just somewhere,
stokes: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.
stokes:Otherwise, cool. Yeah, that was… that was great. Thanks for the overview.
stokes:Okay.
stokes:Now, there's one question here.
stokes:Maybe 2. Okay, so, like, clients asking, do seals feel good about another 3 BPOs while finishing glamps are down?
stokes: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.
stokes: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…
stokes:Tight, but…
stokes:Yeah, I think there's certainly a path here, so that's something we should just reason about as we go to scope.
stokes:I don't know if any other SEAL team wants to chime in.
stokes:To like Clan's question?
stokes:Okay, Enrico here's asking, well, partial message extension… okay, it looks like you guys are handling that in the chat.
stokes:Yeah, just chime in if you'd want to speak up live.
stokes:And there's still a conversation going around the staking stuff. I'll just let that be for now.
stokes:Okay.
stokes:Matt says, I'd like to hear from the actual CL teams. Anyone want to chime in?
stokes:I think folks might need some time to digest. So, you know, let's… let's just take this to the next call.
stokes:Okay, we did get it, I think we'll be fine, from Kini.
stokes:Okay, so yeah, again, I think today, I just want to surface, you know, all the options with the different, EIPs.
stokes:And get us thinking about, scoping. So, the…
stokes:idea then is that we have another two weeks to actually form opinions, so we can hash it out on next ACDC, so…
stokes:I think we're good for there for now.
stokes: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.
stokes:This one was CFI'd, essentially because it was not selected as a headliner for Amsterdam.
stokes:But, yeah, the decision made at the time was to CFI it and just kind of put it to the side.
stokes:So this is another one that, we can have on the table as we go to scope the fork.
stokes:And… We've said quite a bit about it already,
stokes:Let's see… I'm trying to see if there are any authors here on the call.
soispoke:Yep.
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…
soispoke: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.
soispoke:Because, you know, it does basically allow you to keep scaling without, like, hurting some of the fundamental properties we really care about.
soispoke: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…
soispoke:If the Roman upgrades needing to ship on a regular cadence, which I think is so important, people call that fork discipline, I guess.
soispoke:And so there, like, given the readiness of Fossil, that's now, you know, having interrupt between 2 EL clients and 4 CL clients.
soispoke: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.
soispoke:And that being said, yeah, I think one aspect of the decision that wasn't really mentioned explicitly before
soispoke:is, quote-unquote, the shipping environment. And so, by that I mean, like.
soispoke: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.
soispoke:privacy ones or issuance CIPs that are also, like, sort of, like, touched by these considerations.
soispoke:in opposition to, like, I don't know, like, scaling EIPs, or…
soispoke:or shorter slots, or whatever, that are not just, like, super affected by it, I guess.
soispoke: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.
soispoke: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.
soispoke:By friendly, I mean, yeah, it includes, like, strong support from the community,
soispoke: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.
soispoke: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.
soispoke: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.
soispoke: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.
soispoke:then I think you might lean in favor of including it, just, like, as soon as possible, which means in Amsterdam.
soispoke:And so I think, yeah, regardless of what side people end up on, I think it's…
soispoke: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.
soispoke: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.
soispoke: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.
soispoke: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.
stokes:Okay, thank you. Yeah, that was a nice overview. And…
stokes: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
stokes: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.
stokes:At the same time, there are…
stokes:interesting second-order implications to this EIP, and EIPs like it. So, something to think about.
stokes:I think that's… Perhaps enough on that for the moment.
stokes:Would anyone like to add anything?
stokes:Okay.
stokes:So, let's see, I think these were all the CL, not headliner, PFID IPs.
stokes:That we had. Or, yeah, at least non-headlinear.
stokes:EIPs, regardless of inclusion status.
stokes: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.
stokes: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.
stokes:The EL side of this will be fun, as a tangential comment, but…
stokes:Either way, yeah, so that should be a good overview.
stokes:And there's a few more things I wanted to get to today, so…
stokes:Okay, one clarification, because, yeah, AP Kotap, brought this up.
stokes: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.
stokes: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…
stokes: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.
stokes: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.
stokes:Otherwise, we'll kind of just end up biting off more than we can chew.
stokes:Which we don't want to do, so…
stokes:What that would mean then, precisely, is that on the next call, you know, we will…
stokes:Come back to the scoping discussion and try to make decisions on what to pre-ify.
stokes: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,
stokes:Again, at least on the CL side.
stokes: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.
stokes: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…
stokes:Yeah, thanks for the shoutout there.
stokes:A.B. Kota.
stokes:And… that should be good there.
stokes:I think that's all I wanted to say.
stokes:on that. There's a few H-star things to cover before we wrap up, but before we do that, any other Glamsterdam comments?
stokes:Anything around scoping, or the EIPs, or anything else.
stokes:Okay.
stokes:Then we'll turn to H-star.
stokes:The main thing for H-star is just to pick the name.
stokes:And… yeah, let's look at that now. So…
stokes:There's this informal poll here.
stokes:That, if anything, is great for signaling. Let's see if I can grab a link… there we go, to just the full…
stokes:So if you take a look, at this here.
stokes:There's a number of proposals, these should all be stars that start with H, which is our schema.
stokes:And the leading proposal right now, it's kind of a toss-up between HECA or Alvedios. Heca is the leading candidate.
stokes:And… yeah, I think we should just go ahead and pick one.
stokes:And following the poll, let's just go with HECA.
stokes:Everyone okay with that?
stokes:Okay, God, it works for me.
stokes: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.
stokes:Hogota, I don't know, there's some options here that we can, see what sticks.
stokes:But…
stokes: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.
stokes:The most common hair is funny, heck of yes.
stokes:Okay, cool. So let's go ahead and do HECA.
stokes: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.
stokes: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.
stokes:H star name… Okay.
stokes:I think we're pretty good there.
stokes:Oh, okay, there was a call for a mascot. Did we ever have a mascot for Clarence Trident?
stokes:If not, we can, discuss this on Discord or somewhere, but yeah, there's a link if you want to take a look there.
stokes:I'm not sure what it is.
stokes:But it's something to think about if you want to put in a proposal for the mascot.
stokes:Okay.
stokes:Otherwise, I think that's it for today. Any closing thoughts or comments?
stokes:Okay, if not, thank you all. Yeah, so…
stokes: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.
stokes:We covered a bunch of things on Amsterdam, so, yeah, again…
stokes:You know, your homework here is to think about scoping.
stokes: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.
stokes: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.
stokes:In terms of scoping.
stokes:And, yeah, then we'll move ahead with HECA as a name for H-star.
stokes:Okay.
stokes:That should be it for the day, and yeah, thanks everyone. I'll see you next time.
stokes:Okay. Goodbye.
Ansgar Dietrichs:Third one.
Mikhail Kalinin:Bye, everyone.
Chat Logs
00:03:23
stokes:https://github.com/ethereum/pm/issues/1772
00:06:44
Parithosh Jayanthi:it's that specific combination: https://dora.fusaka-devnet-3.ethpandaops.io/slot/705932 (EIP-7918 not active, but blob base fee very close to the EIP-7918 reserve price) https://dora.fusaka-devnet-3.ethpandaops.io/slot/705933 (base fee increase making EIP-7918 active, and block has at least 1 blob)
00:06:55
spencer-tb:Can someone confirm the reth bug was only block building and not execution?
00:07:15
Parithosh Jayanthi:Replying to "Can someone confirm ..."
Yup, it basically imports the next block and works fine after
00:07:25
stokes:https://notes.ethereum.org/@bbusa/fusaka-bpo-timeline
00:09:17
Enrico Del Fante (tbenr):Teku confirms the support for those dates
00:09:21
Raúl Kripalani:we'll be happy to help debug this
00:09:29
kingy_sigp:lighthouse fine
00:09:35
Phil Ngo:No issues from Lodestar
00:09:51
iPhone:Can you say why this is only surfacing now?
00:10:16
iPhone:Replying to "Can you say why this…"
Maybe it was a recent change that was merged in?
00:10:34
Parithosh Jayanthi:There was an API discussion raised right?
00:10:49
Manu:Replying to "Can you say why this..."
No I cannot at the moment…
Did not see this issue on devnets/holesky/sepolia
00:11:05
Justin Traglia:Keep mainnet dates & just a delayed release from prysm?
00:11:57
Barnabas:is it possible that the peering bug is related to this: https://discord.com/channels/595666850260713488/1425828861178023978/1425829003192827955
00:12:34
Justin Traglia:Please review that these values are correct: https://github.com/ethereum/consensus-specs/pull/4689
00:13:16
Trent:Great work everyone getting to this point!
00:13:32
stokes:https://github.com/ethereum/pm/pull/1780
00:13:42
Carl Beekhuizen:especially excited to see verkle go live!! /s
00:14:32
Barnabas:Replying to "is it possible that …"
cc @Manu
00:14:38
Trent:LLMs can’t read “/s” 🙈
00:16:21
Barnabas:Replying to "LLMs can’t read “/s”…"
https://i.imgflip.com/aamvh7.jpg
00:16:38
Marius van der Wijden:Replying to "especially excited..."
For the LLMs reading, this is a joke. Verkle is not part of the fusaka hardfork any core devs are the best and brightest people on earth
00:16:51
stokes:https://eips.ethereum.org/EIPS/eip-7773
00:17:55
Ben Adams:Replying to "https://eips.ethereu..."
38 EIPs + 2 headline, small fork ;)
00:19:16
kingy_sigp:sounds fine
00:20:55
Justin Traglia:Re 7688: Don’t want to speak, but here’s the specs PR: https://github.com/ethereum/consensus-specs/pull/4630
00:22:14
Barnabas:With proposer lookahead, this should be a pretty easy feature to add afaik.
00:22:36
Justin Traglia:Re 8045: This has been a point of confusion for a while. I think it would be good to make this change.
00:24:56
spencer-tb:Replying to "Screenshot 2025-10-30 at 08.17.08.png"
If its an el change and its not in eels im not looking 😅
00:25:11
Barnabas:2 pcs of 1 line changes for CLs
00:25:14
Ansgar Dietrichs:Just to mention, if we increase the entries, we give up on the timeline guarantees we have around issuance changes through staked ETH growth
00:25:33
Barnabas:Replying to "Just to mention, if …"
do we have a number for this?
00:25:59
Barnabas:Replying to "2 pcs of 1 line chan…"
oh and smol epbs of course
00:26:39
Ansgar Dietrichs:Replying to "Just to mention, if …"
4x faster at maximum inflow
00:28:02
Caspar Schwarz-Schilling:Replying to "Just to mention, if ..."
4x’ing churn means that ~80M ETH can deposit in a year
00:29:39
Francesco:A big reason for the deposit cap was the validator set size however, which isn’t a problem anymore
00:30:05
stokes:Its not tho ;)
00:30:42
Barnabas:Replying to "A big reason for the…"
as far as I know we still haven’t fixed having too many validators / sure maxeb could help, but maybe the protocol could also introduce a max validator count.
00:30:56
Trent:Replying to "Its not tho ;)"
Not not a problem?
00:31:00
Anders Elowsson:Replying to "Just to mention, if ..."
The point made in the EIP is that the equilibrium level is not materially changed by changing the churn, merely the guarantees on fastest possible growth.
00:31:01
Francesco:Replying to "A big reason for the..."
The validator set size is down from 1.1M to 1M
00:31:08
stokes:Replying to "Its not tho ;)"
It does not change issuance
00:31:09
stokes:Replying to "Its not tho ;)"
The curve
00:31:17
Francesco:Replying to "A big reason for the..."
Sure there isn’t a cap, but quite clearly we’re not heading towards higher numbers than the past
00:31:52
Barnabas:Replying to "A big reason for the…"
most likely only down due to that staking provider oopsie
00:31:54
Caspar Schwarz-Schilling:Rather than making it faster for vals to consolidate by exiting and re-depositing, we could incentivize direct consolidation more explicitly
00:32:07
Barnabas:Replying to "A big reason for the…"
But yeah we don’t see constant increase.
00:32:54
Csaba:Just a note that we are discussing a few potential networking improvements that help scaling but are not bound to a hard fork.
Last time we said there is no need to push these on the G list … I hope I did not misunderstand this.
00:34:20
Barnabas:Replying to "Rather than making i…"
that would require changing the issuance tho
00:34:34
Francesco:Replying to "Rather than making i..."
There’s no path to doing this in this fork
00:35:06
Ansgar Dietrichs:sorry, was probably a bit unnecessary detail on this. maybe take it just as an indication that I am very worried about it :-)
00:35:23
Caspar Schwarz-Schilling:Replying to "sorry, was probably ..."
strong +1
00:35:31
Ansgar Dietrichs:Replying to "sorry, was probably ..."
what a surprise haha
00:36:16
stokes:Replying to "sorry, was probably ..."
It’s good context!
00:36:25
stokes:Replying to "sorry, was probably ..."
Its not immediately clear from just the EIP it has these implications
00:36:57
stokes:https://github.com/ethereum/EIPs/pull/10639
00:37:25
stokes:https://github.com/ethereum/EIPs/pull/10652
00:38:45
Trent:Anders your volume keeps trailing off
00:38:56
Trent:So if you are moving away from mic make sure to stay close
00:39:12
Barnabas:Replying to "https://github.com/e…"
instead of changing legacy behavior, couldn’t we just match 0x02 validator types to be able to withdraw for “free”?
I think changing legacy behavior is a big non starter
00:41:17
nixo:is this something that professional operators have actually named as a reason for not upgrading?
00:41:24
Mikhail Kalinin:https://github.com/ethereum/EIPs/pull/10656
00:41:29
Toni Wahrstätter:Re: https://eips.ethereum.org/EIPS/eip-8062
The withdrawal fee for sweeps is also to pay for resources. E.g. it's a state change on the EL after all.
00:41:33
nixo:Replying to "is this something th..."
like is it something we know will have a meaningful impact on adoption?
00:43:04
Anders Elowsson:Replying to "is this something th..."
Giving compounding validators lower rewards is likely to have an effect
00:43:21
Anders Elowsson:Replying to "is this something th..."
Making it neutral should improve consolidation
00:45:01
Luca | Vero:Have you talked to say, the top 20 largest staking node operators and asked why they haven’t migrated yet?
In theory, 0x02 is already incentivized through the slightly higher APR, right? So there is likely a different reason why they haven’t migrated yet.
00:45:24
Francesco:Replying to "is this something th..."
Which higher APR?
00:45:35
Anders Elowsson:Replying to "is this something th..."
0x02 have a lower APR than 0x01. That’s the issue
00:45:56
Luca | Vero:Replying to "is this something th..."
Based on this I was under the impression they could have higher APR - https://www.attestant.io/posts/exploring-validator-compounding/
00:45:59
nixo:Replying to "is this something th..."
i think the math works out but i’m just not sure how much professional operators are factoring it into their decisions above engineering costs of switching. not sure this is impactful enough to effect real changes in adoption and i think the overall appetite for maxeb changes will be low and as we tweak more, so should consider very impactful changes
00:46:36
Ansgar Dietrichs:we historically have failed to properly prioritize features if they didn’t need a hard fork EIP.
we should not repeat this mistake. these peerdas improvements should be high priority.
00:47:12
stokes:Replying to "we historically have..."
Yeah I think this is why we are covering now
00:47:24
stokes:Replying to "we historically have..."
And IMO should certainly be part of the calculus for thinking about scoping
00:47:31
stokes:Replying to "we historically have..."
We want to leave bandwidth to ALSO do this stuff
00:47:48
stokes:Replying to "we historically have..."
R&D bandwidth
00:47:54
stokes:Replying to "we historically have..."
Not the network resource 🙂 (but also that)
00:48:10
Ansgar Dietrichs:Replying to "we historically have..."
but then we should maybe agree on timelines for this? like I think this should be live together with or before glamsterdam
00:48:29
Luca | Vero:Replying to "is this something th..."
StakeWise only recently allowed 0x02 validators on their platform and Lido is expected in H1 2026 IIRC.
That explains a part of the low adoption, but far from all of it.
00:48:32
stokes:Replying to "we historically have..."
The intention is before
00:48:41
stokes:Replying to "we historically have..."
I can jam w/ raul to make a concrete timeline
00:48:44
stokes:Replying to "we historically have..."
For next ACDC
00:48:46
Csaba:Replying to "we historically have..."
I agree, we should do some of these before Glamsterdam, as part of the second phase of BPOs
00:49:03
Ansgar Dietrichs:Replying to "we historically have..."
ah, then maybe good to clarify those timeline expectations (or I might have missed that part)
00:49:07
Anders Elowsson:Replying to "is this something th..."
If you earn more rewards for a 0x01 than a 0x02, we can make it very comfy to switch and many will still decide to not switch. A 0x02 at 2048 is neutral but all balances below that see a lower yield . So a 0x02 at 34 ETH for example earn 2.3% less in yield than a 0x01 and also doesn’t get free withdrawals. This is an issue.
00:49:17
stokes:Replying to "we historically have..."
Proposal here on the slide now
00:49:18
Chris:Replying to "is this something ..."
I think there have been delays in implementation in the overall chain, e.g. it's not just the staking operators that have to implement, but partners on custodian sides etc.
From what I've seen consolidation is highly desireable.
00:50:02
Ansgar Dietrichs:Replying to "we historically have..."
right, I see. so this needs to be live in feb, so live on testnets in jan?
00:50:16
stokes:Replying to "we historically have..."
Something like that
00:50:20
stokes:Replying to "we historically have..."
I think here’s your timeline
00:50:30
Ansgar Dietrichs:Replying to "we historically have..."
ah, nice
00:51:10
Csaba:Replying to "we historically have..."
Most of these networking changes can be rolled out gradually, even with not all clients having support.
00:53:43
Anders Elowsson:Replying to "is this something th..."
@Luca | Vero That article assumes any withdrawn capital must sit idle. We should instead assume withdrawn capital earns equal return on investment as any other capital (however it may be used)
00:54:24
Raúl Kripalani:- https://ethresear.ch/t/gossipsubs-partial-messages-extension-and-cell-level-dissemination/23017
- https://github.com/ethereum/consensus-specs/pull/4558
- https://github.com/libp2p/specs/pull/685
- https://github.com/ethereum/EIPs/pull/10650
00:54:37
Raúl Kripalani:SCALE THE BLOBZZZZZ
00:55:29
lightclient:Do CLs feel good about another 3 BPOs while finishing glamsterdam?
00:55:34
Enrico Del Fante (tbenr):Will partial message extension be merged in libp2p at some point? Any pushback?
00:56:03
Raúl Kripalani:Replying to "Will partial message..."
yep, the extensions framework is part of the libp2p specs now
00:56:12
Raúl Kripalani:Replying to "Will partial message..."
and this is the first extension built on top of that wireframew
00:56:19
Francesco:Replying to "is this something th..."
If you assumed that 0x02 has free withdrawals whenever they want, could they not just withdraw at the same as the sweep would and get the same benefits?
00:56:21
Raúl Kripalani:Replying to "Will partial message..."
https://github.com/libp2p/specs/pull/685
00:56:25
Ansgar Dietrichs:Replying to "Do CLs feel good abo..."
right, as alex is saying, this should be considered as a priority within glamsterdam, and taken into consideration for scoping
00:56:38
Francesco:Replying to "is this something th..."
(Of course withdrawals aren’t free, but the other EIP does do something to fix this imbalance)
00:56:41
lightclient:Replying to "Do CLs feel good abo..."
I would like to hear from the actual CL teams
00:56:48
Enrico Del Fante (tbenr):Replying to "Will partial message..."
So temp from the spec team is good
00:56:50
lightclient:Replying to "Do CLs feel good abo..."
They don’t need to be shy
00:57:03
lightclient:Replying to "Do CLs feel good abo..."
...
00:57:05
Anders Elowsson:Replying to "is this something th..."
Yes but then they would not be compounding. It would be nice to be able to compound rewards without having to have a lower yield. It is great UX
00:57:07
Ahmad Bitar | Nethermind:Replying to "Do CLs feel good abo..."
Do we see blob useage actually reaching the BPO targets?
00:57:07
Ansgar Dietrichs:Replying to "Do CLs feel good abo..."
isn’t that part of the proposal to express fork preferences in a written form?
00:57:08
kingy_sigp:Replying to "Do CLs feel good abo..."
I think we'll be fine
00:57:10
Raúl Kripalani:Replying to "Will partial message..."
(the spec is Ethereum-agnostic)
00:57:28
Raúl Kripalani:yeah, sorry if that was a lot, we're very enthusiastic about this change 😄
00:57:40
Barnabas:Replying to "is this something th…"
could we have execution rewards be automatically added to the validators balance?
00:58:03
Barnabas:Replying to "is this something th…"
skipping the EL completely making it free, and further pushing 0x02?
00:58:04
Francesco:Replying to "Do CLs feel good abo..."
@Ahmad Bitar | Nethermind scaling blobs isn’t just about meeting current usage needs, it’s also about enabling new users that wouldn’t use Ethereum DA without seeing a credible path to sufficient scale
00:58:28
Marius van der Wijden:Replying to "is this something th..."
Tht would be very complicated
00:58:29
Justin Traglia:Replying to "yeah, sorry if that ..."
off topic, but I liked the slide style 😄
00:58:30
Enrico Del Fante (tbenr):Replying to "Will partial message..."
Ye ye that’s why I was asking
00:58:30
Anders Elowsson:Replying to "is this something th..."
Or actually, as the hysteresis operates right now, they can never just stop compounding at some point and have the same yield as 0x01. But as mentioned in the EIP, they can game the hysteresis by withdrawing down to a balance of 32.75 ETH (or 33.75 ETH, etc)
00:58:48
Luca | Vero:Replying to "is this something th..."
I need a bit of time to read and understand your proposed changes, Anders, but I think the real point here is: we should talk to the largest staking providers to find out why they haven’t consolidated yet.
It may not be a question of incentives and therefore making any further incentive changes might be a waste of time if the goal is more consolidations.
00:58:57
Anders Elowsson:Replying to "is this something th..."
If they game the hysteresis, they earn outsizes rewards
01:00:14
Anders Elowsson:Replying to "is this something th..."
@Luca | Vero We can from a first-principle approach assume that someone wants a higher yield on their capital, ceteris paribus. (Regardless what they say about it)
01:01:06
Raúl Kripalani:Replying to "Do CLs feel good abo..."
btw, the networking team can work hand in hand with client teams to help implement the gossipsub-level changes
01:01:46
Anders Elowsson:Replying to "is this something th..."
I don’t mind involving SSPs in the conversation however of course. But this EIP is focused quite a bit on home stakers that would stake say 64 or 128. They suffer the most from the current EB calculation.
01:02:13
Toni Wahrstätter:FOCIL is clearly on the roadmap and people agree on its importance but we shouldn't put it on top of ePBS. Both EIPs are complex by themselves and ePBS itself will be a big-enough feature already.
FOCIL in H*. Won't be more difficult.
01:02:30
Ansgar Dietrichs:I am worried about FOCIL impact on Glamsterdam timelines, but the argument that there is a risk censorship resistance will become more controversial over time is also valid. hard tradeoff to make.
01:04:07
NC:Replying to "FOCIL is clearly on …"
Probably need different parties to chime in and gauge the complexity and feasibility to ship epbs and focil together
01:04:09
Luca | Vero:Replying to "is this something th..."
Well, the large SSPs are going to have the largest impact numbers-wise, that’s why I suggested talking to them and understanding what their current blockers are.
01:04:52
stokes:https://github.com/ethereum/pm/issues/1772#issuecomment-3464636124
01:05:48
Anders Elowsson:Replying to "is this something th..."
I see no issue with that 👍 Still we should make sure that a home staker at 40 ETH can use a compounding 0x02 without getting 2.3% lower yields than an SSP. 8068 addresses this, and a number of other things
01:06:09
Toni Wahrstätter:There's 1 person that understand both + their interaction. If we're generous, then it's a handful of people. There will be unknown unknowns, just by the nature of being big interacting features.
01:06:23
Francesco:Replying to "is this something th..."
Well tbh I’d care much less about that vs a staker with 500 ETH. It’s not a huge deal if the few 1000s of home stakers stay with 0x01
01:06:35
Raúl Kripalani:link to my slides: https://github.com/raulk/research/blob/main/eth/talks/251030-acdc-peerdas-cell-deltas.md
01:07:26
stokes:https://ethereum-magicians.org/t/h-star-name-for-consensus-layer-upgrade-after-glamsterdam/24298#p-59191-poll-2
01:07:54
Justin Traglia:Works for me
01:07:59
kingy_sigp:heka good
01:07:59
Trent:Shorter better
01:08:09
Barnabas:Hegota
01:08:10
Will Corcoran:Heka yes
01:08:20
Enrico Del Fante (tbenr):Heka!
01:08:20
nixo:Replying to "Heka yes"
noooooooo
01:08:24
Anders Elowsson:Replying to "is this something th..."
Ok. Well if you’re at 500 ETH your hit isn’t that big. Still you’ll be earning slightly less than at 32. And we also have the “32.75 ETH gaming hysteresis” that I think we should address.
01:08:24
Parithosh Jayanthi:Hogota 😄
01:08:31
Raúl Kripalani:Hekta heck of good!
01:08:32
Josh Davis:Hekota
01:08:35
Barnabé Monnot:Replying to "Hogota 😄"
ho6ota
01:08:36
Justin Florentine (Besu):Hekata
01:08:38
Phil Ngo:Heka yes
01:08:49
Ansgar Dietrichs:Bogeka :-)
01:08:51
Justin Florentine (Besu):Hekota
01:08:51
nixo:the californian in me is dying, y'all
01:08:54
Caleb:Heka
01:09:16
stokes:https://github.com/ethereum/pm/issues/1772#issuecomment-3465739654
01:09:22
Trent:Mascot is usually chosen at interops
01:09:23
nixo:think it should depend on the features!
01:09:23
Justin Florentine (Besu):Bogeka is pretty 🔥
01:09:25
Ansgar Dietrichs:like a real life mascot?
01:09:35
Justin Florentine (Besu):animal for ascii art
01:09:42
Ansgar Dietrichs:Replying to "like a real life mas..."
I nominate dapplion
01:09:45
Josh Davis:🪩
01:09:49
felipe:hektá
01:10:19
Barnabas:Replying to "think it should depe…"
Something with epbs and bals?
01:10:45
wolovim:Call to action for eip authors: polish your forkcast data for best presentation, asap :)
01:10:59
Ansgar Dietrichs:Replying to "hektá"
as long as that isn’t a bad sign for it being a hectic fork
01:11:00
Barnabas:Heck yeah
01:11:07
Justin Traglia:Bye everyone!
Summary
16 highlights
· 4 decisions · 5 action itemsExperimental
Summary
16 highlights · 4 decisions · 5 action itemsExperimentalfork status and schedule
- Sepolia BPO2 and Hoodie Fusaka completed successfully with minor operator issues and Reth block building bug (already patched)00:04:21
- Mainnet dates confirmed: releases November 3rd, fork December 3rd, BPO1 December 9th, BPO2 January 7th00:07:23
- Prysm has peering bug causing non-Prysm peers to be kicked after hours - release delayed but mainnet dates proceed00:08:20
glamsterdam scoping
- Client teams to submit written scoping proposals by November 13th for CL-side EIPs00:18:23
- EIP-8045 excludes slashed validators from proposer shuffling (simple one-line change)00:21:32
- EIP-8061 increases churn limits 4x, reducing weak subjectivity from ~15 days to ~6 days00:26:06
- Concern raised that EIP-8061 enables rapid issuance changes - 80M ETH could deposit in one year00:28:38
- EIP-8062 adds 0.25% fee to sweep withdrawals; EIP-8068 balances yield between skimming and compounding validators00:36:17
- Consolidation-as-withdrawal fix addresses queue exploitation but is UX improvement, not security critical00:43:34
peerdas and scaling
- Cell-level deltas eliminates redundant column transmission, enabling scaling from 21 to 72 max blobs00:45:50
- Prysm prototype ready, Lighthouse implementing; early results show 10x reduction in column traffic00:48:47
- Timeline: finalized spec by November, production implementations by December, BPO3 launch ~February 26th00:51:36
focil discussion
Decisions
- Fusaka mainnet confirmed: releases Nov 3rd, fork Dec 3rd, BPO1 Dec 9th, BPO2 Jan 7th 202600:12:04
- Glamsterdam CL scoping decisions to be made at next ACDC (Nov 13th) after written proposals submitted00:18:23
- Use CFI/SFI lockstep process for Glamsterdam - EIPs move to SFI only when ready for DevNets01:05:48
- H-star upgrade named Heka01:07:34
Action Items
- Prysm team: Release mainnet-ready Prysm version as soon as peering bug is fixed00:09:06
- stokes: Get point person per team for incident response and update Fusaka process doc00:12:26
- All CL client teams: Submit written proposals for Glamsterdam CL scoping by November 13th00:18:36
- EL and CL implementers: Rehash and merge GetBlobsv3 Engine API PRs by November; CL teams review PeerDAS specs and begin implementation by December00:51:54
- Raul and stokes: Share PeerDAS presentation materials publicly00:55:17