All Core Devs - Consensus #190

Transcript

Alex Stokes: Hello. Let's give people a few minutes to join, and then we'll get started.

Let's wait just one more minute or so.

Okay, I was trying to wait until around 40 or so people. Yeah, like Barnabas said here in the chat, Devcon is next week, so people may be traveling for that. Let's, yeah, see who shows up, and in the meantime, we will begin. So, thanks everyone. This is ACDC number 190. is issued 2276 in the PM repo. And I'll drop a link there in the chat to the agenda. So, yeah, today, we have a few Glamsterdam things to touch in on, then, yeah, a few Hegota things, the big thing there will be Scope In. And yeah, let's go ahead and get into it. So… To start, there are a few things that came up with, bid gossip on Glamsterdam.

Let's see… Justin Traglia had the post here. I think there's two PRs here that kind of address the same issue. I don't know if you want to say anything, Justin, about, that? But ultimately, yeah, there's… yeah, these two different solutions. I'll try to grab links to them. And yeah, we should just go ahead and decide on the route to go.

Justin Traglia: Yep, thanks. So, the solutions are from… Potuz and I, and from Nico, the PR that I submitted Pretty much tells the proposer that they should accept bids, or duplicate bids from the same builder, regardless of value. But only as the proposer. Nico can go into… is PR, but essentially it allows builders to submit increasingly valuable bids. Above a certain threshold. I actually prefer Nico's PR, but I'm curious to hear what clients think. Nico, would you like to go into more detail?

Nico Flaig: Yeah, so it solves the same problem, right? The proposer would accept multiple bids. But it basically also makes every other node in the network relay multiple bids of a builder, but at, like, a minimum increment, so… The minimum increment is mostly to, prevent DOS, and, Like, the highest bid rule is still, kept in place that we have, so if there's already a higher bid, then nodes will also ignore bids from a builder. Yeah, there's, like, the formula, it's in the PR. So it's like a 3% increment per bid that you need to do as a builder. And a minimum of, like, 0.001 ETH. That a builder needs to bid up, in order for the bid to be propagated.

The good or the nice side effect for this is that it also makes honest bidding a lot better. Compared to the current spec, because right now builders need to set up multiple indices to do stage bidding on P2P, and with that, you can just have a single index. Where you have all your liquidity, and you don't need to split it across multiple indices. I guess the downside is it allows for more bids to be submitted on P2P, but… It's quite costly because, to increase the bid value, you actually Need to increment it by 3%, and if the bid wins, you need to pay that to the proposer. So that is, like, the spam protection it adds.

Justin Traglia: And you're still competing with other builders as well. Like, I did the math earlier this morning, and… If you wanted… if a builder were to submit a bid up to half an ETH, that would limit it to, like, 200 bids per slot. And then if… If its limit were, .05 ETH, that would be 125 bids. So it's very reasonable still. And bids aren't super large.

Alex Stokes: Okay, yeah, thanks for the overview. Any client teams had a chance to look at this? Okay.

Barnabas Busa: Are we comfortable with the 3%, by the way? Just because it's like a weird number. I'm not sure where it's coming from.

Nico Flaig: So that was what I had for a while in Lodestar, but we can, like, just analyze more mainnet data to tweak this. It's like the cost you need to, like, at the lower you set it, the more competitive you make the auction, P2P, but the higher… Said it, more costly, so… Just needs to be some better…

Barnabas Busa: Could this not be just a client implementation detail? Like, why do we have to output this in the spec?

Justin Traglia: So it's, it's useful for builders to have a consistent implementation of this. Otherwise, they would just, go… or sorry, they'd submit bids for the lowest denominator, so if, like, one client implemented 1% and the rest implemented 3%, They don't know who the proposer is, so they would increment by… 1%. Or they'll do the highest, I forget, but it's just inconsistent and complicated for them.

Alex Stokes: Yeah, Potuz?

Potuz: I just want to express my dis… my discomfort with this kind of EIPs. We are already over-complicating and over-specifying this topic, which is a global topic. It's going to float… I'm going to be able to flute the chain. I understand that There are ways of preventing DOS by adding this minimum increase. However, we are already doing crazy things, like allowing for bids to propagate on their non-finalization, coming from different forks, and we've already seen bugs in our caches. dealing with these dependent roots, because we decided to go with this design of allowing a lot of bids over P2P. I think we should keep this topic as simple as possible. What we have today, it's fine.

The bug that this is… that triggered all of this discussion is a crazy bug in which a builder sends out, for everyone a very high bid and directly connects to a proposer and sends a very low-valuable bid. It's completely solved at the proposer side. There's no rational reason why a proposer would want to ignore any bid, so… Even… even… it should be fine, even if we implement Nico's PR. The proposer should not ignore any bid that comes to it anyways, even with lower values. Because I am the proposer, I can just put whatever bid I want. So anyways, we're going to be implementing a thing that is… the proposer doesn't ignore anything, and I would want to prevent this…

topic to taking over P2P. I don't see any reason why we would increase complexity over this, and I would anyways try to prevent this on Prysm. I would feel much more comfortable just accepting one bid than having to have a cache and checking from each builder what was the latest increase, or what is the latest increase that I have. And add computations to this topic. It just doesn't make any sense to me.

Alex Stokes: Okay. That's a fair point. Yeah, there… meanwhile, was some support for the 76 route, PR5776. But it sounds like it might need a little more time to stew. Is it going to impact anything if we take another call to make a decision on this?

Justin Traglia: It actually would.

Alex Stokes: move sooner.

Justin Traglia: Yeah, I mean, this… this is fixing a bug, technically.

Potuz: Yeah, it's fine to include either. I'm just saying that most likely, we're not going to implement this. It's not a hard fork, and it's not going to prevent any bug. If one does or it doesn't. We can just keep discussing this later.

Alex Stokes: Okay. But then it sounds like it's okay to go ahead and merge 76?

Potuz: I would rather not, I would rather merge the other one, which is just a comment, and leads to the clients to deal with the problem, instead of, like, actually specifying something in the spec.

Alex Stokes: Yeah. Okay.

Justin Traglia: I would like to leave it open for another day, just to give my teams more opportunity to review it.

Alex Stokes: Yeah. Is this something we can make a call? Are we having ACDT next week, or was it canceled?

Justin Traglia: Pretty sure it was canceled.

Alex Stokes: Okay. Yeah, I mean, I'm fine to give it a little more time, but yeah, I guess let's not let it linger too long. Yeah. I guess it would be good, just, yeah, in the event that other client teams are listening to this after the fact, just… a call out to review Potuz's comment. That. It might be better to kind of leave this, open to implementation. And yeah, then from there, I guess we can figure out the best path forward. In the next few days. Does that sound good to everyone? Okay Thank you.

Enrico Del Fante: Yeah, the only side effect is… is that… If any client implements some weird things, then reference tests are running, the gossip validation might have been problems. This is cool.

Alex Stokes: Sorry, Ms. Steph. You said… could you say that one more time?

Enrico Del Fante: Sorry, it probably was far from the mic. I'm saying that the only side effect could be that there might be some interaction with reference tests, if some clients implement their own… Filtering, and then reference tests, maybe trigger some… some of those. Right. The client needs to be… to be… have… to have something like the reference test way. And then the production way, so, you know…

Alex Stokes: Right. I mean, yeah, I think if, you know, if this ends up in that scenario, and it's, like, a restriction, then we should make sure everyone…

Enrico Del Fante: Anyway, it's… Each client needs to deal with it anyway, yeah.

Alex Stokes: Yeah. Okay. Cool, okay. Thanks, everyone, for your comments there. Let's see, I think, yeah, that covered that, and there was one other thing that came up, I think just some nice things for the fork choice here, this was 5770. Let's see, Justin, I think you had more context on this, if you would like to say something?

Justin Traglia: Yep, sorry, there are some… Missing checks in the execution payload gossip validation function for Gloas. We're just adding some, Checks that existed in fork choice into the gossip validation so that you're not gossiping invalid execution payloads. It's just, yep, nice to have.

Alex Stokes: Fair. Is this PR ready to merge, or do we need any discussion with people here?

Justin Traglia: I believe it's ready to merge.

Alex Stokes: Okay.

Justin Traglia: I would like to hear what others think, since it hasn't had a proper review on GitHub.

Alex Stokes: Yeah. Any takers? I got an LGTM in the chat. I, myself, haven't been able to look at this too deeply, but yeah, it looks… looks reasonable. We could do the same thing, give this another couple days, Justin, and then, once we get a few more plus ones from the client teams, go ahead and merge it, if that works.

Justin Traglia: Yep, that sounds great, thanks.

Alex Stokes: Very. Cool. And let's see what's next. Okay, I think that was it on that topic. The other thing I wanted to touch on, there was, I think, yeah, just some discussion around… Thinking about, CFI to SFI, which actually this should be a Hegota thing. And not a Glamsterdam thing? So in that case, any other Glamsterdam things that we should touch on? Okay.

Barnabas Busa: Maybe just, maybe we can discuss what is the rollout plan here, because we have, quite a few Consensus, changes then happening. I expect that we would want to have another devnet coming up sometime. Where we can test all of those, we can probably have a new… Better release.

Alex Stokes: Yeah, I think the plan is another Consensus-specs release, and then devnet could be good. Again, I think these are all pretty backwards compatible, and then, yeah, just a lightweight check on a devnet would be good.

Barnabas Busa: Well, there was a PR from Lido that would not be backwards compatible. That would be a consensus-breaking change, so that would need actual explicit testing. In the… in the future, David.

Alex Stokes: I see. Yeah.

Barnabas Busa: I'm just curious about what kind of timelines we are looking here, because if you don't have the spec release out this week, then we most likely won't have it out next week. Which means… probably the earliest we can look at launching it, and it is sometimes around the 16th to 20th of November. Just pretty late,

Justin Traglia: I'm gonna plan on making a spec release probably this time tomorrow.

Barnabas Busa: Okay. And then… yeah, I don't know if we can have the implementations ready before DFI. Highly unlikely, I would say.

Justin Traglia: I also think it's a bit unlikely, but maybe by, like, Wednesday or Thursday? I don't know.

Barnabas Busa: Yeah, I'm not sure.

Alex Stokes: Yeah, I mean, I think we'll just do the best we can. Potuz is saying here in the chat that Kurtosis might even be better than a devnet for that particular thing. But yeah, I mean, especially given that Hoodi's a bit up in the air right now, We do have some time. We shouldn't let it linger forever, but… Yeah, I think there's enough time to run these trucks. Okay, any other Glamsterdam things? Okay. Then, thanks for that. We'll move then to Hegota, and… Yeah, so… what was I going to do here? I think I put this… comment on the CFI SFI thing in the wrong spot, but I guess we'll just go to that then.

Because, yeah, we've started progress with Hegota devnets in different forms and fashion. And, yeah, I think there's just some confusion about this, this could be open discussion. I will say that… I have a comment here for, you know, my thinking on how to think about this, Which is essentially, like, again, start with the headliners, so have a Hegota devnet with FOCIL and frames. then… you know, I think the rest of the EIPs so far are much lower complexity or size than quick slots. Just given, you know, all the application layer work that will have to happen there. So, I would suggest we basically, you know, think about adding those next in the sequence. Have quick slots worked on in parallel, and then merge it back in. Quick slots, that is, you know, a bit later in the process.

Oh yeah, Heze, but we'll get to Hegota devnet soon, I assume. So… I don't know if anyone has any comments on that, or… yeah. Anything they'd like to add? Okay. I heard there was some discussion on ACDT, and I was hoping to help resolve things. NC's asking, when can we make a decision to SFI the two smaller EIPs? I think we should get a stable Hegota devnet first, and then make that decision. That's what I would suggest.

Barnabas Busa: They are already merged into the Heze spec, so I think that would be a… I'm a stick.

Justin Traglia: But you don't have to… sorry, it doesn't have to be SFI to be merged to the Heze spec. But I agree that we should maybe SFI one or two of those smaller EIPs.

Alex Stokes: Okay. Do we think we're gonna make progress on this question, or are we good without them?

Justin Traglia: I think we could decide to SFI right now. I'm just, yeah, depending on what clients say.

Alex Stokes: Any client teams have any perspective here? Did you mean, I think, Barnabas, you said that some things already have been merged to the specs? Which were those?

Barnabas Busa: Yeah, and we've been testing it.

Alex Stokes: But which were they? It was 8015, and was there another one?

Barnabas Busa: Yeah, 8015, definitely can be SFI'd now. The other one, I would prefer to make a change to it and then specify it.

Alex Stokes: I see, okay.

Potuz: The other one is about the zero, the BLS, withdrawal.

Barnabas Busa: Potentially.

Potuz: Barnabas?

Alex Stokes: Right.

Barnabas Busa: Yup.

Alex Stokes: But you still have a PR open for that Barnabas?

Barnabas Busa: I do, yeah.

Alex Stokes: Yeah.

Barnabas Busa: It's also on the PM repo. I want to bring it up today. So maybe this is a 10th right now?

Alex Stokes: Sure, yeah.

Barnabas Busa: Yeah, so… Where was this going? So it's EIP8365. The other one? And, So this is originally NC's proposal, and I made some suggestions to, remove the burn ability, so basically, making sure that after the fork, you… You would still not burn, your ETH if you make a 0x00 deposit, and If there's any queued up deposits, then, Those queued deposits would be still processed as the old mechanism, and new deposits would be burned. That's what NC proposed as the alternative for this. Which, yeah, I guess… Really, the question here is, whether we want to…

burned the ETH or not burn the ETH after, we remove the 0x00 deposit capabilities.

Alex Stokes: And it'll be simplest to leave things as is, but then you'd basically be burning your ETH at that point.

Barnabas Busa: Through?

Alex Stokes: It's simplest to leave things as is, but then, with this change, you'd be burning your ETH if you deposited that way? That's the consequence.

Barnabas Busa: Yeah.

Alex Stokes: Yeah, I mean, I like simple. But I'm curious what other people here think.

Barnabas Busa: Like, I feel like my change is also… doesn't introduce anything fundamentally new, to the Beacon chain, so we are not adding anything new logic or anything, it's just setting some different values into different values, that's it.

Potuz: But we keep some values on the state. Like, dropping the deposit at… I'm not completely against your proposal, but it's definitely simpler just to drop the deposit, and that's it, and burn that… that… that money.

Barnabas Busa: Yeah, of course, I 100% agree with that. The goal is that maybe we can have a long-term plan, for post-quantum view, where, you know, like, this… commit for the next three forks that, you know, in the following fork, we're gonna be stopping the new 0x00 validators, and then, in the following fork in ISTAR, we can exit all the remaining 0x00 validators, and then, a fork after, we can remove the BLS change. BLS to execution change completely. But yeah, I think it would be good to have all these SRA clients dedicated to this long-term goal, and then we can also have a blog posts about this. So that people can be prepared, like. What we were planning to do.

Ben Adams: Is it… is it common at the moment? Are there many, 0x00 validators been created.

Barnabas Busa: No, it's not common. So, like, removing it from the state is… It's plus or minus a few milliliters, it really doesn't matter, for the state size growth. So keeping it there, it adds barely anything.

NC: Well, you can also argue the other way, right? Because it's so minor. Then why not just keep the protocol simple?

Alex Stokes: Yeah, I mean, the other way to handle this is what you're suggesting with this, like, multi-fork advisory period, where it's like, you know, we start communicating Very soon, that this is happening, and then give people some time just to adapt and be aware.

Barnabas Busa: Yeah, I'm just really not a fan of burning ETH, especially if you can avoid it. resolution.

Alex Stokes: Yeah, I mean, I think… I think we generally all agree. Okay, so… then, in terms of moving forward here… What I would say is… Well, okay, I guess you… One Consensus before merging these PRs? Barnabas?

Barnabas Busa: I'm sorry?

Alex Stokes: Yeah, I'm just wondering about the sequence here. Because, yeah.

Barnabas Busa: Yeah, like.

Alex Stokes: ready. as soon as people agree to this change.

Barnabas Busa: Yeah, like, I want to have a decision basically made whether we want to burn the ETH, or whether we want to do the activation gate, where… what was NC's original proposal, basically.

Alex Stokes: Yeah, I mean, I think we'd all lean towards avoiding burning ETH, and then the question is just how complex is the change? And, yeah, I'm just skimming this myself. It doesn't look too wild. But yeah, I mean, in terms of today, like… Do client teams feel good about this? Should we just go ahead and merge it in? And to be clear, this is not SFI this EIP, it's just updating this CFI EIP.

NC: I also want to point out that, Barnabas' proposal That means that the 0x00 validator's balance will be zeroed out, and automatically submit a deposit To a deposit queue. when… DevOders amidst the BLS execution change. So… Realistically, that deposit will be automatically Going back to a pending deposit queue. And then, do the, activation. And then become the 0x01. Validator? So… is… In the case that, if the 0x00 deposit was really, submitted by mistake, and the user wants a refund instead of a 0x01 validator, it will go through the entire deposit queue, and aggravation, and then withdrawal. Before they get the ETH back.

Barnabas Busa: Yeah, but that's, I think, fine. This was to avoid a possible attack where someone would make a bunch of 0 deposits after this fork goes live, and then all of a sudden, it would just do a BLS change, and all those validators could become active, basically. In one epoch.

Alex Stokes: Why were they not… I don't see the difference there, like… Regardless, any deposit would just go through the typical life cycle, right?

Barnabas Busa: Yeah, so they would definitely go through the lifecycle, but they would not be an active stake. So it would be basically a passive stake, and that would not be part of the chain, so this could lead to some… some… I'm not sure, actually, if it would be an attack, but it could be an attack where a large sum of ETH becomes active at one specific epoch.

Alex Stokes: Yeah, I don't see…

Barnabas Busa: So that's why it would just need to go through the deposit queue once again, to make sure that this is not attackable this way.

Alex Stokes: As in, that's more work you need to do, or… I didn't follow the last part.

Barnabas Busa: No, so this is already part of the PR that I made. So that if, if you have a 0x00 validator and you make a BLS change, then it would, go back to the front of the queue, of the deposit queue, and it would have to wait, its activation, just like for a brand new validator. And then they could, then accept their Validator if they want to.

Alex Stokes: Okay.

Barnabas Busa: So it's not about, basically withdrawing the funds, because, Yeah, withdrawing, we'll have to wait for the withdrawable period. But also, with 0x00, you couldn't have withdrawn your funds to any execution layer address. That is not possible, so… I don't think we're losing anything here, to be honest.

Alex Stokes: Okay, I mean, yeah, just going off of what people have said, it sounds like there's weak support for this, so I would lean to go ahead and do it. Yeah, I mean, the other option is just… I'm not sure people have had that much time to look at this that deeply, so, you know, we could just defer this one call.

Barnabas Busa: Well, we could definitely defer one call. I would just like to have the client's opinion, whether they would want to Keep the ethore. our burned 8. That's it. And if… then we can, like, figure out later what… and how we want to keep the ETH, not burnt.

Alex Stokes: Okay. Okay, so… yeah, we should be able to… For those of us that'll be at Devcon next week, yeah, we can touch on this in person. And then continue the conversation, and then, yeah, let's just go ahead and defer this for the next call. Then from there, yeah. We'll have a clear idea on what we want to do, and then we'll move forward. Yeah. Okay. Kev, your hands up.

Kevaundray Wedderburn: Yeah, I just wanted to clarify that if we do a blog post today, 0x0, depositors that start depositing from today would still be accepted. It's only if they deposit after the Hegota hard fork, right? So they can still be in the deposit queue. By the Hegota Hard fork. to me, it seems like we're just protecting against the people who deposit after the Hegota hard fork, and we already know that it's not a lot of people using 0x0, so I'm… it doesn't seem to me like this is the best approach. I mean, I understand not burning ETH, but if we give… Enough, like, like an announcement now. It…

Barnabas Busa: Yeah, but, like, you're assuming that every single Validator on the internet will go to the Ethereum blog post and read that announcement, right? Like… that's just… I know that we put out some information, but that doesn't mean that everybody will be informed of Such and such change. Like, there are definitely tools that have deprecated this functionality already, yet we still see 0x00 deposits made on mainnet right now.

Kevaundray Wedderburn: Right, yeah, I agree. I just wonder what's gonna change, like, is there some amount of time that we need to give For the notice, before we can say people have been given enough, like, time. Because this question will come up whenever we choose to burn the ETH, right? So is it, like, we need to…

Barnabas Busa: My point is that we don't burn the ETH. That's the whole point.

Alex Stokes: Hello.

Barnabas Busa: the Validators active, and they could just migrate to 0x01, and then become a normal validator that is actually supported.

Alex Stokes: Yeah, I do want to be mindful of time here, and it seems like this needs more conversation. So, in terms of moving forward today, let's just say we'll definitely make a call on this, two weeks from now. But, yeah, that means, you know, those of us at Devcon can have these conversations there, and otherwise, yeah, async, we can keep things moving. It does seem like, yeah, it's kind of a split between people who say, leave things as is, because it's simpler, versus, yeah, let's just have this… Backstop, let's say, that we know, there won't be any burnt ETH, so… That's, I think, a good summary to date, and yeah, let's then go ahead and move forward.

And… yeah, Barnabas, you had a lot of comments. Let me just see where we're at.

Justin Traglia: Could we, go back to specifying 8015.

Alex Stokes: Yeah, yeah, that was the next thing, so…

Justin Traglia: I'm sorry.

Alex Stokes: do that. Yeah, jumping back to 8015, again, yeah, this is, I think, a pretty small change, and it sounds like it would facilitate the testing in devnets. I feel like everyone here's okay with SFI. Any opposition? Okay, lots of thumbs up. Okay, great. So then, we will SFI… Let me just quadruple check the number, 8015. And this is just cleaning up the Beacon state, so pretty straightforward. Cool. Okay, then… Barnabas, you had a comment about, FOCIL clarification. I think this can be pretty brief. Do you just wanna… Give the PSA.

Barnabas Busa: Yeah, so I noticed that, in the engine forkchoiceUpdated, in the execution API spec, we don't necessarily clarify if we want to rebuild the block with the inclusion list or not. And I noticed that on devnet 3, that when I start spamming some transactions in the inclusion list only, then, some of the ELs will basically drop Drop their payload and start, regenerating the payload again, at, like, 6 seconds into the slot. Which basically leads to a bunch of missed, blocks. So my peers, Basically saying that if, If we have some attributes already part of the payload, then the inclusion list Should basically just append to it, and not generate a brand new block.

NC: I think we probably need, EL's input on this, whether it's okay to implement this. I think from CL is fine.

Alex Stokes: Yeah, Toni's here in the chat saying, it's… Not that straightforward. So, do we want to bring this topic to the next ACD?

Barnabas Busa: Sure.

Alex Stokes: Okay. Cool, thanks for raising it, but yeah, again, just from the CL side, it sounds… I think, yeah, what you're saying it sounds pretty straightforward, less so maybe on the EL side, so… Let's pick up that thread there. Cool. Let's see, I think that was the Hegota stuff, other than the scoping… Let me just double-check the agenda. Yeah, okay. So then let's pick up with the scoping here. We have a few more EIPs to get through. And hopefully we can round that out today. I will share the Forkcast list again, like I've been doing. I feel like that's pretty helpful, but I'll need one second to click all the buttons. Let me do this. One second… Zoom is not cooperating.

Okay, there we go. Okay, can everyone see this? I'll make it a little bigger. Does that look good to everyone? I can't easily see the chat here. Okay, I see a thumbs up. Cool, okay, again, I think we can just take this from the top, except we had said we were gonna do… Fast execution payload broadcast last, just because it came in very near the deadline. So, let's do that. Then in that case, first up, we'd have EIP8334. This is bundled attestation propagation. Sukun here is the champion. Is Sukun on the call? I don't know if you'd like to say a few words, and yeah, then we can…

Sukun Tarachandani: So, I can present a small slide showing the benefits of it.

Alex Stokes: Sure.

Sukun Tarachandani: Okay.

Alex Stokes: Yeah, I think I have to stop sharing, and then, yeah, if you could… yeah, you can take it over now.

Sukun Tarachandani: It will be very quick, yeah. I have only 4 sets. So, we basically simulated Decoupled Consensus, which is scheduled for ISTAR on a cloud network, thanks to each Barnabs and Barnabas, thank you so much. So, I'll just give you a brief background of the simulation, and basically how EIP8334 helped here. So, the idea is, yeah, basically we stubbed Prysm and just assumed all the network is safe, so a lot of the fork choice details were crossed over, but the whole aim is that we wanted to bring down finality by 4x, meaning that we have 16-slot finality. And, basically, the idea is that on this devnet, we tried to map nodes, load on a single node to be as much as it would be on a mainnet. So, as you can see on the right side's comparison, in ISTAR, we expect a single subnet to have 2,000 validators, and in our simulation, we had 25% more, and then we have a split between home nodes and super nodes. So, I'll basically just show you the benefits of 8334, and basically, the benefits are for home nodes. Like, if you run a super node, you're, like, all good.

Okay, and this is, like, the slot schedule, so you have a block, you have a payload, you have data columns, you have goldfish votes, you have other things also happening. And the simulation had a bug where the PTC votes were delayed, but for the specific thing, it does not matter. And FFG votes in a subnet are cast in, like, this staggered fashion across 7 seconds. And there are 64 such subnets on mainnet, and in our case, there were only 2 such subnets, and the node is in 2 subnets, which is exactly as it is on mainnet. So you can see the data usage for a home node. This is standard gossip sub, nothing, no EIP8334.

And, like, the outbound is completely choked, it crosses well over a 25 MBPS line. Here, basically, it does cross the 25 MBPS line rather than being flat, because the measurement is done at the time of enqueuing in the queue, and not at the time of actually sending out, and since my queues were pretty big, so you see it is 40 MBPS outbound, but this actually would have flown off over a period of time. Okay. And basically, yeah, that sort of is the point, that with our current system, we need roughly, like, 40 Mbps of outbound capacity to make it work, and also, like, it's just generally difficult, and also it interferes with these goldfish votes a lot, which are…

sort of important for decoupled consensus. They're, like, very important, actually, for the Valid chain. Yeah, so what 8334 does is this very simple idea that instead of sending all the attestation data separately, and repeating it again and again, we bundle it together and, like, just send the attestation data with signatures, and even a bundle of 4 items will give you almost half the… half of, basically, the benefits. It reduces bandwidth by half, yeah. So, quickly, basically, this is the home node data usage in that case. It roughly looks similar, but the scale is basically half of the previous one, so that's why this is 20 Mbps. And this is 10 MBPS here. So, yeah, basically the scale is half of that. And I will just show you the comparison slide, which is…

Yeah, so the lighter one is the first scenario without 8334, the second one is the second scenario with 8334, and, like, that is a lot of difference, and the reason that we want this for ISTAR, at least, is that This then allows us to play around a lot with the slot structure. So, this slot structure that I showed you is not currently fixed. We're trying a bunch of other things. But for those other things, it would be really great that we have some leeway in our attestation, like, sending capabilities, and we can, like, move them around a lot. Yeah, so… that's basically for the benefits. Now, I'll leave you with some details in the sense that, like, and to open up the discussion, which is that currently the EIP uses partial messages. I have modified the EIP to also work over Waggle.

Which is a new system that we are working on, and I would like to propose it to be included with Waggle, and it will be backwards compatible, it does not need to be fork aligned, but the whole thing is that we should get it by ISTAR, so that we get a lot of benefits for decoupled Consensus. And to just add one note, this would also add with PQ votes later on, when the vote size is pretty large, because Waggle gives you this very nice capability that you can like, easily move from push mode to fetch mode, and which is, like, really nice for PQ modes, because PQ modes are really large, so we'd like to reduce our fan out and move to a pull-based system.

Yeah, so that's about it.

Alex Stokes: Okay, thank you.

Sukun Tarachandani: Oh, by Ocean time… okay, chat questions. Good question, name inspired from. Joao can answer that.

Alex Stokes: Or, maybe another question here, if we accept the EIP for Hegota, do we… yeah, like, what would.

Sukun Tarachandani: Actually, no, yeah, you would need a very little change, basically. So, this data… like, as much change as you would need to do to your finality votes on gossip sub, you would do the same change here. So, the only thing that changes is that this format of attestation data, you'll be putting a different SSZ object here as, like, as it is currently. So, right now, you vote for two… a source and a target, and… as checkpoints with their slots and the head. Then you would vote for a finality height and the target, and basically, they would have both source and target. But the change is very little. In fact, it is actually so little that come ISTAR, if we actually have reasonable adoption, I'll also propose this for PTC and Goldfish Forts.

Alex Stokes: Okay. So, yeah, what we would get now with inclusion in Hegota is just the bandwidth savings for bundling the attestations, and then also it sounds like it definitely lays groundwork for decoupled consensus and later forks, so… Sounds pretty nice.

Sukun Tarachandani: Let's see…

Alex Stokes: Yeah, I can go back here now. And… Yeah, so… yeah, that being said, so, yeah, Prysm was in favor, but otherwise, I think support was pretty mixed, at least we can see here from the client rankings. Any client teams want to update their opinion, or, yeah, speak to either side of inclusion here. Okay, sounds like we have Lighthouse is in favor, Looks like then, yeah, you've increased the ranking from before. I'll also take this as a Teku, readjusting upwards. So, looks a lot more favorable for CFI. Anyone else?

Barnabas Busa: Anyone from Lodestar maybe can chime in. They have one of the lowest scores?

Alex Stokes: Anyone from Lodestar? Nimbus, Grandine.

Saulius Grigaitis: I think it's… maybe we can… Meteorize it later? I mean… For me, it doesn't look that important, At this stage. Maybe if there will be time, enough free time. After a while, we can check again this feature. So that's our opinion.

Alex Stokes: Okay. Anyone from Nimbus on the call? Or Lodestar? I guess, yeah, there's a comment here I'll take as representing Lodestar, just, yeah, essentially… Going for a smaller fork here. It would be nice if people could speak up.

Sukun Tarachandani: It's actually a very simple thing, like, you just have to move some bits of gossip-sub onto your thing to track votes accurately, but the change itself is… it does not affect other parts of your CL, so, like, it's a very self-contained change.

Alex Stokes: Okay. I mean, it sounds like…

Nico Flaig: So doesn't it need to update the attestation data, you said?

Sukun Tarachandani: That would update, but that can flow in through the same flow as your gossip-sub-flow. Like, it can just plug into it.

Nico Flaig: Because in Electra, we went out of our way to not update that, and keep the index around, so… At least in Lodestar, editing the attestation data is a big change. We looked at that for decoupled Consensus. And it's not small. Just wondering if it's worth to touch this before decoupled Consensus?

Sukun Tarachandani: So, attestation data is not touched, but the outer object is touched, basically. The Validator ID and the signature is moved around, but the data itself stays the same.

Alex Stokes: Is this a change to the state transition, or is this just the networking data-time.

Sukun Tarachandani: Market is a purely networking change, like, this thing is, like. sort of sits between your node and gossip, so think of it that way. But it won't affect that part of the codebase at all.

Alex Stokes: Yeah, I mean, I think that was maybe Nico's concern, because that was definitely…

Sukun Tarachandani: Yeah, so that's Like, attestation data completely does not change, it's just a data structure transformation at the network layer to, like, sort of better mechanize it.

Potuz: But I assume that then hardening at the fork, it's probably subtle. I… I don't know if your proof of concept has this, but typically when we are changing an object that we're… and then we… during the first few slots of the fork, we're gonna be still gossiping attestations from the previous From the previous epoch, which can still be included in blocks. And… and then we need to also be gossiping these other types.

Sukun Tarachandani: I doubt that these kind of things are easy. …out of a fork, basically, yeah. So, it does not affect that part of the… like, it… this transition does not happen at a fork. It can be introduced middle of a fork.

Alex Stokes: Yeah, but I guess Potuz' point is when we do add this, then, you know, say you support it, and then your peer supports it, and then the issue is you kind of have to think about both formats, at least for some time. Although, I guess, yeah, I mean, is there some way for me to know that my peer supports this? Because then… I think you would just have to… it would be subscribed to that channel, right?

Sukun Tarachandani: Yeah, so… so you would know your peer supports it, and… but yeah, for that duration, you have to support both if you want to be backwards compatible.

Barnabas Busa: I think the nicest way would be to do this default transition. Like, subscribe to both. Two epochs before, and subscribe to both during epoch after 34. And then just help everyone migrate over.

Sukun Tarachandani: That would be ideal for me, at least.

Alex Stokes: Okay. I'm hearing support for this, especially given people's comments today, adjusting the client rankings. Do people feel like the concern… the other, you know, otherwise the concerns raised here have been addressed? Okay, one thumbs up I can see there. Yeah, I mean, it seems like CFI, so… Okay, I guess, yeah, final, final comments. Otherwise, seems like we should CFI this, and then we can move forward. Okay, I guess I can go off these emoji ranks, too. Okay, cool. So then let's go ahead and, CFI8334. Thank you. Okay. Next up is 8383 here on the list, and this is reducing the retention window.

So, with this one, I think we had touched on it a few calls ago, and… if I recall correctly, there's a question of, sort of, yeah, this exact epoch number, and thinking about the window. Kev here is the champion. Kev, would you like to say anything here? Any updates, or otherwise, do you think it's, yeah, ready for consideration as is?

Kevaundray Wedderburn: Yeah, yeah, I think it is ready for consideration. We spoke quite a lot about the retention window for Glamsterdam. I can paste in an issue that… error. Yeah, we spoke quite a lot about the retention window for Glamsterdam, so, I think it's ready for consideration.

Alex Stokes: Okay. So, then yeah, and maybe just, yeah, for… to double-check my understanding, this would just be changing a parameter in the config, right?

Kevaundray Wedderburn: Yeah.

Alex Stokes: Okay, so pretty lightweight change, at least in terms of the code artifact. Might have bigger impact, just given second-order effects, but yeah, that being said… Let me actually go back here. So yeah, this one, yeah, the people who chimed in didn't seem too excited, just going off the rankings here from Prysm and Lighthouse. It'd be good to hear then, if those have updated from those teams, and then otherwise from the rest of the CL teams, if you have any thoughts on this. One question here, Kev, in the chat, it's a single value change.

Kevaundray Wedderburn: Yes, though we've sort of aligned a lot of the windows already, so it's a single value change that, changes things like the history expiry for the EL, the blob… sorry, the bowel retention window, so that's what we did in Gloas, just to align all the windows, and then this basically just brings the number down more. So, it's a single value change. But, yeah.

Alex Stokes: Okay. It would be good to hear support from a client team. Okay, getting some now in the chat. Lighthouse. Saying CFI. plus 1 from Lodestar… do we need to revisit the exact value? I mean, that's… yeah, should be straightforward to do, but… Okay.

Kevaundray Wedderburn: Yeah, no, no… No strong opinion on the value. I would note that we have a different EIP, by Toni as well, that, is for the reorg… retention window… I forget the EIP number. That also uses 8192. M…

Alex Stokes: I mean, aligning them just makes it much more easy to reason about the whole system. Again, people are quiet today, but we got quite a number of thumbs up on, you know, the suggestion to CFI. So, I think we go ahead and do that. Any opposition? Otherwise, I'll call it, and we'll see if I have this one. Okay. Then, let's go ahead and move 8383 to CFI. Again, this one looks like it should be pretty lightweight, so that's good. And… okay, yeah, thanks everyone. We'll move to the next… one here. Let's see… had we talked about…

Dima Gusakov: We had not, because you've been changing the order that we are moving, and we got lucky enough to be the last.

Alex Stokes: We had touched on 8205, right?

Dima Gusakov: Breasted.

Alex Stokes: up back there. Okay, yeah, so we had started this last time. Yeah, Dima, I don't know if you'd like to add anything else to here. Otherwise, yeah, we'll open it up for the client teams.

Dima Gusakov: Sure, yeah. So, where we ended up last time, as far as I remember, at least, that there is a broad consensus between client teams that the issue that we are trying to solve within this EIP, which is a deposit front-running vulnerability. Is a real issue, and it should be solved. And the other consideration was that, well, it might be solved in post-quantum, so why would we do that? Hence, my proposal is, we CFI this EIP, And at the point when we understand that in the post-quantum deposit contract, or by any other means, this vulnerability is fixed. we drop this EIP. If it's not, we keep it and implement it. Because without this commitment, we have a real chance that this vulnerability will stay with us even in the post-quantum world.

So, again, my proposal is to CFI that, and then drop it as soon as we understand that there is a better solution in post-quantum, if any.

Alex Stokes: Yeah. I guess one thing there is just we don't know when we would know that, right? Like… understanding what the PQ solution looks like might take longer than… You know, even shipping this particular fork. It's not, you know, that's not really a point against what you're saying, just making it clear. That we might not know.

Dima Gusakov: Yeah, it might, but dropping it right now would be a clear indication that there is basically no commitment to fix this thing at all. And if we keep it as CFI right now. And even if by the time we are approaching the fork and we are, like, at the very end of the implementation or whatever. we can either prolong this commitment or move this EIP to the other fork, worst case scenario. Or, if we clearly see that PQ implementation is not ready or far from being ready, we can implement it, because from the implementation point of view. This thing is indeed very simple, and according to our research, and while talking with many of you who are on the call, and many other security researchers and people.

We were not able to figure out or to get an opinion about what is the better way to solve the problem that we are facing with this deposit raise.

Alex Stokes: Yeah, makes sense. Yeah, then… oh yeah, Kev, go ahead.

Kevaundray Wedderburn: Yeah, I was just gonna say that there is currently, like, two, proposals for the PQ deposit, contract. There is the… the proposal that explicitly splits the staker from the operator, This doesn't solve the front-running issue, but it disincentivizes it, because if you get frontrun, the operator can't, it doesn't top up the operator's balance. You'd have to just withdraw so you get refunded. The other proposal is basically what we have today, and we… yeah, in that, that obviously doesn't solve the issue either. So those are the two proposals. One of them is closer to today, the second one, is different, but it only… it doesn't solve the front-running issue. It just means that you can be griefed.

The EIP is, 8413, I believe. Yes.

Alex Stokes: Okay, but then the EIP would… you know, the intent is to resolve this front-running issue, and I guess you're saying none of that work would? Touch on this?

Kevaundray Wedderburn: Right.

Alex Stokes: Okay. Yeah, so then, looking here for today, again, the, you know, original client rankings… We got Teku here, otherwise not great support. Anybody want to chime in here? With an updated view. you know, to the extent that there's problems here, it sounds like 8205 would address it, and doesn't sound like we have anything else directly in the pipeline.

Dima Gusakov: I would really like…

Alex Stokes: many clientele.

Dima Gusakov: Yeah, client teams to speak up, because the silence is pretty confusing.

Alex Stokes: Oh, yeah, it's just hard to read. Okay, yeah, Teku's saying they stand by what they had said, which is good. Do you want to add any color, Barnabas?

Barnabas Busa: This… issue… Yeah, it's… I don't know if you should be solving this at the protocol.

Alex Stokes: Okay. Yeah, I mean, I think it would be nice to have more support from the client teams on this. And… if there aren't any updates today, I think we need to go off the rankings that they originally wrote. So, any client teams? Trying to give you a chance here. Yeah, I mean, again, I'm not… not hearing any support. Oh yeah, Kingy, I mean, the Lighthouse, you know, was against us.

Yeah, okay, I mean… I'm not really hearing anyone want to speak up for this. Okay. Maybe Kingy doesn't have a mic today. They're loose saying they want to look at it. Yeah, okay. It's late for you. Fair enough. Anyone from Prysm?

Dima Gusakov: Potuz, come on, speak up, your kids are not sleeping, I know.

Potuz: Oh, my kids are in school. I… I actually don't really understand why they're decoupling it from… from post-quantum, so that's why I'm, I'm shutting up on this one. I… typically would tend to… I agree that this is an issue. I agree that, the solution seems to be safe, but we've said so many times and end up, like. changing EIPs and finding a lot of bugs in the last few months. So, if we anyways are going to have to solve it under post-quantum, I don't see why there's a rush. And I didn't understand the argument as to why to decouple this from post-quantum.

Dima Gusakov: Yeah, but the problem is that there is no consensus that we have to solve it, and that's what bothers me. So…

Potuz: I am happy to say that we want to solve it, and if any ways we're going to change the deposit flow, we should push to solve it then, or just even commit to solve it then, or work with the post-quantum people. But I'm completely in favor of solving this bug, which is an existing bug. What I don't understand is why adding the complexity now, when we know we are going to have to change the deposit flow.

Dima Gusakov: Right. You are absolutely right, and that's why we have Kev here, who previously commented that neither of the current implementations actually solves the issue. So that brings us to the point that probably none of the, like, maybe none of the future implementations will solve it either. So if we have two options now, neither of those solves the issue, it's a clear indication that we need to solve this issue separately, and we can do it now. Well, at least we can consider doing it now, because again, we are not making an SFI decision, we are making a CFI decision.

Alex Stokes: Yeah, I mean, maybe just some color there. I think people are agreeing that this would, like, should be solved with PQ, and yeah, then what kept saying today is we don't quite have something right now, but… If anything, it sounds like, you know, the commitment that we do have is to resolve this, definitely, with the move to PQ, and then the question is, yeah, just based on the scope of Hegota, if we want to move ahead with this or not. And, yeah, again, from the core devs perspective, I'm not hearing a majority of support for it. In which case, I think we go ahead and DFI.

Dima Gusakov: Yes, you can, but again, what, like, and answering Barnabas' proposal, like, why not let it go and reach out to PQ people to solve this issue? Well, we for sure did. The thing is that… All of the solutions are exactly like that, or some sorts or flavors of that. There is… But I think this is just…

Potuz: because they are trying to reuse the current design, and trying to keep it as minimum as possible. But, I mean, if we agree that this has to be solved, and anyways we are going to have to touch the deposit flow, then PQ is the optimal place to do this.

Alex Stokes: Yeah, so… I'm not… oh yeah, Greg.

Greg K: Yeah, do you hear me?

Alex Stokes: Yep.

Greg K: Yeah, so I, actually, I definitely agree with Potuz, here. The main point that, yeah, it's worth discussing today, whatever the decision is, is, is, perhaps it's the same as Dima going to say, that, you know, one issue is that perhaps you might have new deposit contracts. but not mitigate this problem, or mitigate this problem and create a new one. There is a whole family of problems, which the root of them is that you first have to deposit ETH, and then the node operator has to do something. So the main… like, I don't care about this EIP in particular, like, you can have another solution, this is totally fine, but what should be flipped is the… the process, like, first there should be some…

transaction which does not deposit it, which is the node operator commitment somehow, whatever it is. And second, after the node operator has done this, transaction, then to have the… deposit or deposit indicates. That's the main… the main point. And this, I think, is not considered yet in the post-quantum design as, a priority. So, I agree. If we have some commitment, or some agreement that we will definitely solve it in this post-quantum, and not introduce a new attack, so we have this kind of new architecture. or somehow solve it somehow, that's totally fine. What worries me a bit, and I was… I had also some, private call chat with Kev, is that the current PQ design does not solve it, and if we DFI today, then perhaps we might, get into the situation that this just never gets solved, and whenever this new post-quantum contract is the time to come into place, then again we will not have time, so it will be again the same argument, you know, we have this architecture right now, but let's not make it all more complex, let's not delay the, you know, ISTAR fork, whatever it is at that time.

and let's just keep the problem existing forever. Because this is something happening when something gets DFI'd, and they will say, let's do it later, and… then there is something else urgent. So, by CFI now, what do we… what gives us time is to have, let's say, for next couple of months, to figure out the kind of optimal PQ deposit architecture, and if we have this, of course, this EIP could be withdrawn. So it's not that I am personally married with this EIP. The point is to make sure that this would be solved, right? So, yeah. So, the main thing that perhaps core dev teams could, agree or disagree today is that this should be definitely solved, at least in the post-quantum contract. Because this is not… this was not clear to everyone, at least, like, from the post-quantum team, if I understand well. It's not clear that this is something important to solve.

So it's different saying, this is important to solve, but not doing now, than saying. this is not important to solve at all. So, if we can reach at least a rough consensus that this should be taken into account on the post-quantum deposit contract, that's… good enough for me, I would say. But some of the, you know, for example, I think EF Labs or some other, you know, rankings, they were saying, this is not a problem, this is not important, this is not a priority, something like that. So, it's different to say DFI because we don't have time in Hegota, and we will include post-quantum. I'd rather say DFI because this is not important, this is not a problem. So if we can just at least reach a consensus that this is a problem, it's just the timing of Hegota, not optimal, and let's do it in, let's say, ISTAR, or whatever is the post-quantum deposit contract, that's… that could be…

A way to deal with it from now on. So this is the… what I would like to hear, some opinion, and then we can move on. Nope.

Alex Stokes: Well, I think this is what people have been saying. So, you know, they agree with the problem, it sounds like the consensus among core devs is to solve this definitely with PQ. I do want to be mindful of time, and I think the right way to move forward right now is to go ahead and DFI this EIP today, but yeah, like, have this call… serve as the commitment that this is an issue that we'll resolve with PQ, and it sounds like that has the backing of the courthouse. So… Yeah, what Potuz is saying here. That, you know, I believe what you're saying, Greg, is… Essentially, what the other core Devs have spoken so far, have been agreeing to, so… What's DFI 8205.

And… yeah, that being said, you know, this is, like, a very strong call-out that this is a… part of the PQ design we need to very carefully consider. Okay, let's then move to 8148, one of the last couple here. And yeah, Dima, I think this is back to you. This is, yeah, allowing this feature of, custom thresholds for the sweep.

Dima Gusakov: I have a presentation for that, so Alex, I need you to…

Alex Stokes: Yep.

Dima Gusakov: Permit me to share my screen. Okay. To fund staff. From hard debates to a very fun, interesting, and great EIP. Okay, 8148, custom sweep threshold for validators, and why do we even need it in Hegota? Let's start with the basics, what's the problem? So what we have today, except on top of this wonderful animation that I personally absolutely love, is we have type 1 validators, where you have 32 ETH, any rewards above, automatically transferred to withdrawable wallet. User experience that people used to over the ages, well, actually over the… 3 years or something. And then we have type 2 validators. Exactly the same, but with 2048 ETH. And… yes, you can move, some stake away from Type 2 Validator, because the…

Minimal activation balance of 32 ETH, but to do that, you need to do it manually. You need to do a partial withdrawal, which is a subject of an exit queue, you need to do a transaction, and so on and so forth. So, if we speak primarily about this amazing experience illustrated by these animations, we have a choice of 32 or 2048 ETH. And that's the core of the problem. Why? Because, well, not that many people have 2048 ETH, and we believe this stops consolidations a lot to what we are proposing. Well, we're proposing to make The size of the Validator custom, or set a custom sweep threshold. And not just custom. But also configurable, so that after you create your customly sized Validator, you can change the size of this validator moving forward.

Using execution layer contract, somewhat similar to what we have in 7002, for example. So, with EIP8148, there will be no more choice between 32 and 2048 ETH. there will be… Anything in between. Starting from 32, ending up at 2048 ETH with one ETH stack. And again, you can set it when you create your Validator, you can configure it later, so you can raise it, you can lower it. Doing a partial withdrawal before that, and so on. So let's talk explicitly about the benefits of the EIP. Well, first one is that with this EIP, we will finally have just one type of withdrawal credentials that fits them all. We've already discussed, previously on the call, deprecation of Type 0.

Validators. But we still have type 1 and type 2, which… It's not the best situation in the world. With this EIP, you will only have type 2 that will fit them all, because you can have still… you still can have 32 ETH validators if you wish, you can still have 2048 ETH validators, and any size of the validator in between. We believe that with this EIP, we will get faster and more consolidations. As you can see right now from the consolidation queue, the only major spike and the only actual interest in consolidation was from Lido. And currently, our consolidations are unstop, not because of that reason, but still. Without Lido, no one else is basically consolidating.

And the majority of the people I talked to indicated that people, I mean, protocols, people, professional operators, indicated that this liquidity concern, this… them losing this ability to get rewards automatically, is the deal-breaker for them to go and consolidate their validators. There is a potential to raise MaxEB, because this 2048 ETH limit in the current EIP8148 implementation can easily be raised without introducing a new withdrawal credential type, without migrating any validators, and every other validator already existing on Ethereum would keep their custom sweep threshold value, so their size, and later on, they will be able to opt-in and decide whether they want to go bigger or not. And there will definitely be a reduced withdrawal queue pressure, because most of this day-by-day withdrawals will be now served with sweep withdrawals.

Now let's talk about expected effects of this EIP. First of all, we expect, realistically, from 3% to 10% more of Ethereum state being consolidated in the near term, should this EIP be implemented. This is a rough estimation based on internal demand within Lido. from CSM stakers, and conversations with multiple professional operators and non-custodial staking operators who are still using Type 1 Withdrawal credentials, specifically because of this liquidity concerns. There is an immediate improvement in UX for the new validators, because EIP8148 allows you to set the size of your validator when you are creating it. So if you are starting with 256 ETH, for example, or even more weird number, like 2050, You can now set the size of your Validator precisely to this value and enjoy your sweep rewards from, I don't know, next week or something like that. And there is no more dilemma for you, either to go with Type 2 or Type 1. You go straight to Type 2.

There is a real potential to deprecate Type 1 validators in the future, should this EIP be implemented, because again, there will be no need for Type 1 validators anymore. And we'll have hundreds of happy zkers, for sure. You might ask me what's the demand for this EIP, and am I just talking here because…

Alex Stokes: Just a time check, get the speed up the slide.

Dima Gusakov: Yeah, yeah, yeah, yeah, yeah, sure, it's just… it's just two more minutes. So, there is definitely a huge demand, both from staking protocols, solo stakers, and professional operators. Briefly on what's already done for this EIP. We have Consensus specs that are already merged into feature folder. We have spec tests that are waiting to be merged should this EIP be CFI'd. We have system contract code ready, and the system contract itself is not that much different from the existing system contracts that we are using for 7002 or 7251, and Lido will be happy to pay for the audit. And we have a working proof of concept for Prysm, plus Kath, plus even DORA, all thanks to Manu, so this EIP is working, and we have a real estimation on how hard it is to implement it, and spoiler alert, it's very simple.

Now to the final notes. This is a future-proof, small additive change, so not a deal-breaker, not a consensus-breaking change, just a small thing, easy to implement, but really adds value. Independent security researchers reviewed and approved this EIP so that they haven't found any major issues to the Ethereum should this EIP be implemented, and they genuinely think that this is a valuable thing. current state with two types of withdrawal credentials is misleading, and I bet someone else, someone will argue with me on that. And Hegota is the best time to have this EIP, because moving forward, you guys will have a lot of work with PQ stuff, and so on and so forth. So, given that the EIP is pretty simple, and Hegota is mostly EL heavy rather than CL-heavy.

I definitely think we should consider it for implementing in Hegota. Final note for those who are very concerned about potential state bloat because of this EIP, there is a potential to change specs a little bit, and use unused bytes in withdrawal credentials, not just for the initial sweep value, but also for the future changes. It's just… thinking… Thinking about the questions you might ask. So let's have this EIP NK go down. Now straight to discussion.

Alex Stokes: Okay, thank you. Yeah, any… any immediate comments? I can get the Forkcast page back up. Yeah, Manu?

Emmanuel Nalepa: Yes, sorry. Just paste into the chat as a link to the present example request, yes. The spec itself is quite easy to understand, the implementation, at least in Consensus layer on Mikhail node is very straightforward RAN and with low complexity, and also, yes, I did a proof of concept in DAS directly, and in DORA, just check out the link I… the support request link I just pasted, and you have everything you need to understand inside introducing to guests and to Dora. I think this EIP has a great, added value versus complexity, ratio, so yes, let's include it in Hegota.

Alex Stokes: Thanks. Yeah, going off the client rankings here, you know, definitely more support for this. Would be good to hear. I guess, yeah, Lodestar, doesn't look like you had an opinion on this? I don't know if you have updated that view. Any of the client teams who were not as strongly in favor, want to say anything, no?

Barnabas Busa: I think it would be good to discuss whether we want to actually deprecate 0x01 validators. In order to have Consolidations, too.

Alex Stokes: That would be a different EIP.

Barnabas Busa: That would be a different EIP, but in the scope of doing that, this EIP would be… Kind of fundamental.

Alex Stokes: Okay. Seems like there's a lot of demand, I'm just gonna say 411. Yeah, in that case, I mean, yeah, it seems like… There is support for this? I mean… It is more mixed. Okay, so yeah, Lighthouse is saying they would update if other people are in favor? Which it sounds like they are. So, I think with that, it does kind of change things to support a CFI. I suppose then I'll ask for… Final comments? Not the CFI? Otherwise, we'll go ahead and do that. Okay. Then, let's go ahead and CFI this. 814… sorry. Too many numbers today. 8148, we'll go ahead and move this to CFI. Okay. So, thanks, everyone.

Then… okay, we had this VOPS EIP, which is informational, and yeah, I wasn't entirely sure if we needed to touch on that, so I think we'll probably just leave that for now. And that leaves us with this last EIP, 8411, that we should discuss, and that should finish out the scoping. So, yeah, this is Kamil. Is Kamil on the call.

Kamil Salakhiev: Yes, I am not cold.

Alex Stokes: Great, yep. If you'd like to share anything?

Kamil Salakhiev: Yes. Yeah, can I get this…

Alex Stokes: you're insured?

Kamil Salakhiev: Yeah, one sec. Yeah, go for it. Really briefly to remind what the EIP is, because, like, based on what I heard, yeah, not everyone's kind of aware. Yeah, basically, it's a fast payload broadcast EIP. The problem is that, yeah, we're using gossip-sub today in a very naive way, so we just forward the full messages. That means in order for any peer to propagate any message, it first needs to download this message in full. And that really has very bad consequences for large messages, because, like, yeah, that slows down propagation a lot. And with… considering that we're increasing the gas limit in Glamsterdam, and who knows what would be the gas limit in the… Hegota, and also, like, there is potentially,

well, we might, decrease the slot duration. Yeah, this problem for fast payload broadcast gets even more important. Yeah, there were, like, some people were curious, like, how much it's important, like, whether we have it… and how… like, what the effect of the EIP, so basically, yeah, that's the comparison, like, if we do just gossip sub, that's my simulations with, like, 4,000 nodes using EIP-7870, and we can observe that, yeah, with, even with very pessimistic assumptions, where we have very slow nodes, if we have this EIP, where we basically… what we do is we are not sending the full message, but we're chunking them into smaller shards, and then propagate them individually. Yeah, we're already cutting, well, increasing the propagation, like, 3X, at the very least.

Yeah, I should say that's basically everything that I wanted to show.

Alex Stokes: Thanks. But, yeah, any… any… Comments? Let me get the screen back up while we're doing that. Okay, yeah, so I think partly because this one came later in the process, I'm not sure client teams originally had time to look into this, but yeah, it'd be good to hear… Out of the people who ranked, yeah, it looks like Nimbus wasn't… super in support, but then Lighthouse and Prysm were. It'd be good to hear from Grandine and Lodestar, Teku. Okay, there's some… CFI support in the chat.

Barnabas Busa: Is this optional?

Potuz: No, it's a hard fork.

Alex Stokes: Okay, I mean, yeah, just going off the call today, it does sound like there's support to CFI this. Any client teams have any questions? Or, yeah, reasons not to CFI.

Kamil Salakhiev: Sorry, I lost connection in the worst possible moment. I'm here. Pure. Okay.

Barnabas Busa: No, you're good, yeah. brick, yeah.

Alex Stokes: Yeah, there's…

Kamil Salakhiev: Residential.

Alex Stokes: support. So, okay, then yeah, propose CFI… 8411, any, any final comments?

Barnabas Busa: What do we want in the next devnet?

Alex Stokes: Let's not talk about that today.

Barnabas Busa: What's up one more minute.

Alex Stokes: I have something to say. That's not bad. Okay, then sure, let's go ahead and CFI8411, and yeah, then we'll move things forward. And yeah, Mark here has a nice TLDR for the decisions, thank you for that. Cool, okay, so that should wrap up scoping, and we are at time. But I have an announcement that I will get into now. The announcement is that I'll be stepping down as the ACDC moderator. Replacing me will be Ben Edgington as lead moderator, and Will Corcoran as deputy moderator. You all know Ben, he literally wrote the book on the Beacon chain. You may not know Will as well, but he's been very active with coordination on the lean and PQ calls, and yeah.

Essentially, you know, his involvement here will help to add redundancy just into the role. And yeah, essentially where Ben needs help with logistics or coordination, he can assist there. So, yeah, Ben here, he's gonna start as of the next call, in 2 weeks. So yeah, we're there. And separately, yeah, thank you all for, I guess, your participation while I've been moderator. It's been a lot of fun. And yeah, super excited for this next chapter with Ben and Will. I don't know, Ben, if you have any, anything you'd like to add to that?

Ben Edgington: Yeah, thanks so much, Alex. Not gonna lie, I am absolutely terrified. I look forward to, dealing with you all and, this immense privilege. Thank you so much. I do want to say a massive thank you to Alex for committing to finishing off the Hegota scoping. And not dropping me in the deep end. I really appreciate that. Looking forward to seeing many of you at Devcon, and back here again in two weeks. Let's go!

Alex Stokes: Okay, amazing. Yeah, super excited. And thank you all. Okay, I'll see many of you at Devcon, and yeah, I'll, I'll see you around. At some point, so… Let's wrap up. Thank you.

Kevaundray Wedderburn: Thanks, Alex.

Alex Stokes: Okay.

Justin Traglia: Hi, everyone.

Potuz: X.

Barnabas Busa: Thanks, Alex.

Toni Wahrstätter: Thank you, bye-bye.

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