All Core Devs - Consensus #179

Transcript

Parithosh Jayanthi: Hello, everyone. Let's wait another half a minute, and then we can start. Oh, am I not audible for anyone, or is it just bonus?

Nixo: We can hear you.

Parithosh Jayanthi: Oh, yeah.

Josh Davis: Loud and clear.

Parithosh Jayanthi: Okay, let's get started. Welcome to ACDC number 179. The first item on the agenda is gonna be a Glamsterdam DevNet 4 update. Do you want to give us the update, Barnabas?

Barnabas Busa: Can you guys hear me?

Parithosh Jayanthi: Yeah.

Barnabas Busa: Yeah, so, Glamsterdam devnet 4, has been, struggling to stay alive. We have had some issues, starting, I think, on Monday, and Ever since Monday, we have been unable to recover. Currently, we are still investigating what the actual root cause of the bug was. There seems to be a Lodestar implementation bug. But I think we are still not 100% sure, and, once we are, confident, that we know what the bug was, then, we can relaunch, with the same spec, just the following, answer the number.

Parithosh Jayanthi: Lodestar seemed to be hinting that it is a spec issue, and we need to update the spec, right? Has anyone gotten some time to look into it?

Justin Traglia: I'm not sure that it's a spec issue, but I will investigate more later.

Parithosh Jayanthi: Oh yeah, I see there's a part of the thread I haven't caught up on. Yeah, okay, Potuz is also arguing that it is a spec issue. Okay, if… I guess an implementation bug would explain what's going on with Lodestar, but most or all the clients on the network seem to be down, so, has anyone looked into why the other clients are down? Okay, yeah, I guess it's probably more of a cascading issue, and we might know more soon. It seems that a few people are on vacation, so maybe it might just take a bit longer. Yeah, abandonments?

Barnabas Busa: Yeah, one more thing, so probably the cascading effect was caused by Watchtower, rolling all the images all at once. Which probably led to a bunch of the same clients just restarting all at the same time, and I think that could have had something to do with it. But yeah, it still shouldn't be this catastrophic, in my opinion. I'm gonna be looking into fixing the watchtower bug, possibly shifting by some random number of minutes, so that we don't have to scan the bug, or maybe add, add some health check into it. I'm not sure what the correct approach would be. Either way, it shouldn't be this catastrophic.

Parithosh Jayanthi: Yeah. Yeah, the plant should be resilient to this. Okay, that sounds good. Yeah, Nico?

Nico Flaig: Yeah, so from Lodestar's side, there is a bug in our fork choice, where we didn't check for the payload data available in should extend payload, so that meant, So we implemented this new feature where you reorg a payload if the data is unavailable, but basically our fork choice, voted for full. So we basically reorged our own payload, and we always build on the wrong chain, basically. But never updated it in our fork choice. But yeah, it doesn't really explain why the network died.

Parithosh Jayanthi: Yep. So, I guess if it isn't a spec-related issue, do we then wait for the Lodestar bug fix, and then relaunch the DevNet? As DevNet 5? What's, planned there?

Barnabas Busa: Yeah, so I wouldn't increase the scope, Until we have at least a stable DevNet4 spec, for at least you know, two weeks, and then looking to, adding additional EIPs to the scope.

Parithosh Jayanthi: Yeah, that sounds good. Moving on to the next topic, it's more of an FYI, but the target gas limit PRs brought up at last week's ACD, last ACDC have been merged. So, both the execution API as well as consensus specs. I just wanted to make a note there. And on a related topic, the builder deposit overflow So, in order to prevent billier deposits overflowing, we've kept, Glamsterdam testing at 190 million. Has anyone else got some time to do some deposit benchmark tests? Do we have some new numbers? Any update on this topic?

Justin Traglia: I'm aware the Prysm and Lighthouse can handle new builder deposit spamming. I have not been able to test other clients. Or prove that they work.

Parithosh Jayanthi: Okay, and by… they're able to handle it, essentially, they're able to do 8,000-ish deposits?

Justin Traglia: Yep, that's right.

Parithosh Jayanthi: Okay. That's good to know. Maybe just a quick recap for photos, we mainly spoke about Labsed on DevNet 4, as well as, if anyone's gotten time to debug it. If you did and you want to say something, please feel free. Otherwise, we had already moved on to other topics. Okay, Yeah, so the next, agenda item is, produce block V4 with, payload. We have an open PR here. And the Beacon API specs. Does someone want to present it or discuss it today?

Shane Moore: Hey guys, I'm Shane, I, made the PR. I think it's in pretty good shape overall. The whole idea is just introducing the idea of being able to get and post, payload envelopes, and also, produce block V4. I think a couple, like, just lingering things to kind of discuss that are interesting are, like, how we want to handle Builder Boost Factor and, the new produce block. I mean, previously. It could be that you would be comparing some value from the ex… for local block building, the, local payload. with a value derived from the execution layer, and I compared that against the, potential value from a external block being built, and then compare the two, and you use this build or boost factor to decide whether or not you want to really prefer local block anyway, or you can, like, really scale up the factor to prefer… to prefer the external, block. Or you can set, like, the factor to, like, 100 and let the two values be compared.

Doesn't really make so much sense, I think, for Gloas, since, like, if you're… you're comparing bids now, and for a local block building, that value would be, zero for local, and then for external block. Whatever they set as the bid. So, we want to keep the build a boost factor, which I think Miko has some interest, then maybe it's more like a Boolean, where we could say, like, either A, prefer local block. always, or B, just accept whatever is the… This did, because you can't really compare. No more… It doesn't seem to make sense to have an actual factor. Just my thought.

Parithosh Jayanthi: And Nico, do you want to bring up the question?

Nico Flaig: Yeah, so I don't really understand why we cannot compare local versus the bid. It should be exactly the same as with Gloas. Because essentially, you just look at your local payload value, and then you pick whatever's the highest bid you have in the pool locally. And then you apply the BuilderBoost, to those values.

Shane Moore: Really, the local bid's value is zero. Pardon, I missed.

Nico Flaig: Local bit of zero. Wait, why is it 0? So if you said, build a boost factor 0, right, we multiply by zero, which means we always pick local block.

Shane Moore: Dear. That would be true.

Nico Flaig: And if it's set to 100, you basically always pick a bit instead of local. And then everything in between, you still apply the… Ratio to each value, and then calculate based on that.

Shane Moore: Yeah, but I mean, the local bid's always zero, so, like, if you do anything higher than zero, you're always going to prefer the.

Nico Flaig: Oh, no, yeah.

Shane Moore: Whether it be 100 or infinity, because right now, it's kind of like… BuilderBoost factor of, like, 0 or 100, or, like, 2 to the 64 minus 1, I think, are kind of, like, the three kind of common values as examples. But you…

Nico Flaig: Yeah. I mean, you don't…

Shane Moore: It's like a Boolean now, really, more so, as opposed to, like… after.

Nico Flaig: bid, right? Like, if you do a local build, the bid itself doesn't really exist, it's just a placeholder. In a sense, in the block like a dummy, more or less. You should just use the local payload value.

Shane Moore: a local payload value being the value from the EL that we were previously getting before Gloas. Compare that to a bit.

Nico Flaig: Yeah, exactly, like, it's the same as we do today. You just look at the local payload value, and then… Instead of getting the header from the builder API, you would look at the bitpool, and look at the value there.

Shane Moore: Okay, I thought they might be, like, apples to oranges, comparing, like, bid to, like, a CL value, but… okay. So then, yeah, it would work the same as today. That's true.

Parithosh Jayanthi: Yeah, Potuz?

Potuz: I just had a question, because I got confused by Nico's comment. So how does this boost work? Forget about the issue of, like, having zero or not, and if you grab the local value, so what… what are… what is the whole branch of numbers that we can have? You multiply, and then you divide by 100, or…

Nico Flaig: Yeah, it's the same as the current spec we have. I think Prysm has this local boost, flag.

Potuz: Yeah, we had it in a way in which you wouldn't be able to boost the external builder, and then we changed it so that we have now these two different flags, one that conforms to the Beacon API, and the other one that that is ours, that has only positive range. So I want… I just want to make sure that at least you have the option of always boosting the local payload. from what you said, it didn't sound like it, so that's why I'm asking.

Nico Flaig: So how it works on the API, it's called Builder Boost Factor, right? So if you set it below 100, it boosts the local payload. If you set it above, it would boost the builder payload.

Potuz: Okay, perfect. So it wasn't really 100, but it was, like, sort of max you in, what makes you always choose the builder payload.

Nico Flaig: Yes, so 100 will just compare value to value, like…

Potuz: Yeah, that's what…

Nico Flaig: buying anything.

Parithosh Jayanthi: Okay, so, is the decision then to close this PR, or make a modification? What would the preference be?

Shane Moore: I mean, I need to at least, just… make sure, like, close out the conversation on this little boost factor. It seems like it worked the same as today, so I'll just make sure that the description, is good for that. The only, like, other thing I introduced a couple days ago from, you guys' suggestion was to introduce a blinded execution payload envelope, like, for when you're doing the safe pull path. basically, for Staple, if you're trying to get the payload envelope from the beacon node, then you really only need a blinded envelope, since the beacon node, the full payload, so you can sign that. Then, whenever you post it back to the Beacon node, you can send back a signed blinded payload envelope.

If you are going the staple path. Else, if you're doing stateless, you can send back, like, the full envelope with blobs and, KG commitments or proofs. But, that's, like, a small PR that I could then merge into 580. And, yeah, Nico looked at it, but of course, it'd be great to get more eyes on it.

Parithosh Jayanthi: Okay, sounds good. Next agenda topic, maybe it also matches well with, with Tony's comments of CLS can handle 8,192 deposits, what about more? Do we want to bump the limit in Hegota? And if we were to increase the deposit costs to 42K gas, we'd run into the problem at 350 million gas limit. Yeah, do you guys want to bring the discussion from chat to the call? Maybe Tony, Potuz, Barnabas, one of you?

Toni Wahrstätter: Yeah, I can do so. Yeah, I was just wondering, like, 8,192 deposits? That's then possible, like, as of $350 million. And then it would be nice if… We had some change in Hegota. That either bumps the number or introduces stable containers. like, I'm not opinionated on the final solution, nor that we… Somehow fix this.

Parithosh Jayanthi: Yeah, Potuz?

Potuz: I really think we're just wasting too much time on this theoretical problem. we can make this limit infinite now. We have, like, several months to punish anyone that is willing to waste, or at least to lock, thousands and thousands of ETH. on the changes to attack and overdose this. So if someone is willing to send constantly 8,000 ETH of deposits, and then wait months to withdraw them back and keep them back, I'm sure we can just coordinate a fork to punish that group. So I think we're wasting too much time. Just make this limit infinite, and that's it, and let's just… Deal with this if it actually happens that someone is willing to waste billions and billions of dollars.

Parithosh Jayanthi: So you'd propose just changing the limit from 8,182 to UN max or something.

Potuz: Well, yeah, so something that… UN match is going to, like, require a lot of hashing, but some reasonable limit. Like, more than the available ETH.

Barnabas Busa: Wasn't the idea to just remove this whole number with stable containers?

Potuz: Yeah, but we don't have civil… well… I don't want to continue changing the spec. Changing just and adding just a limit, it's just easy now, it's just a constant. If we have stable containers and we are testing this, then it's easy to just really fix it that way. But as of now, just changing one constant removes this discussion and saves us time.

Justin Traglia: It's not exactly just changing a single constant. It will be more annoying. I believe it involves a new config variable and stuff.

Potuz: Why would it change anything but just… just the constant that is the limit in the list?

Justin Traglia: Those aren't set as constants, those are set as, I think, presets or something.

Potuz: Yeah, that's fine, this is a constant in our code.

Justin Traglia: Okay.

Parithosh Jayanthi: Is that the case with every client? I remember Nimbus had a hard time changing or touching any presets in the past. Yeah, phone numbers.

Barnabas Busa: My point was to wait for stable containers, because if we add this now, and then we end up doing stable containers anyway in Glamsterdam, then we would need to remove it. So I just don't see the reason to… Add something now, just for the sake of, sake of unlocking… unblocking us, so I would only add this new value if we DFI, Stable containers. the IP.

Justin Traglia: I also agree. I'd rather not make this change without stable containers.

Parithosh Jayanthi: Yeah, agreed. It doesn't, doesn't make sense to add that culture now. Cool, I will put this as a result for now, but we do need to revisit it before we agree to ship plans to them. As in, some fix has to go in. Cool. Okay, the next, anything else on this topic? If not, we'd move to the next agenda item. Okay, the next one is, about the SSZ-ing of the engine API. As always, we had these two proposals. First one is, just adding SSZ-ing the existing engine API from Barnabas, and the other ones from Marius, which kind of rethinks everything. Has anyone been able to dig a bit more into this? I know that, Yasek posted a few messages about it on ACD, but besides that, has anyone given some deeper thought?

Barnabas Busa: I would like to highlight that Nethermind and Erigon now have their implementation of 764 in their tribe branches. And we do not have any CL implementation of either of them, I think, in any of the trunk branches. Also, I'm not very opinionated which one we do. I would just like one of them to be decided on, ideally today, and then we can close the other one. inferiority.

Parithosh Jayanthi: But do we have any information for or against one? Either one? I mean, yes, we have some implementations of Of one, but there isn't a reason to choose it.

Barnabas Busa: I think ethrex did a benchmarking of both of them. I'm not sure if they have published the numbers yet.

Parithosh Jayanthi: Casey, do you maybe want to talk about the Prysm trade-off?

Kasey Kirkham: Yeah, just that we already have a JSON RPC client, and it might be easier to, wedge SSZ into that, but I think that being able to drop, JSON RPC at Hegota is a pretty huge advantage to jumping straight into what Marius is proposing. So, a tiny bit more scope versus a faster deprecation path, I feel like the faster deprecation path is a big benefit.

Parithosh Jayanthi: Yep, that's a fair point. Marius, if we were to go with… with your PR, would, would you be the one leading this? Because, historically, the problem with a lot of API discussions is they're very fertile for bike shedding, so I don't want to choose one of the options where we don't have someone who's willing to Keep up with the bike shedding.

Marius van der Wijden: Yep, happy to lead this.

Parithosh Jayanthi: Okay. Cool. Then let's go with, Marius's PR, purely for faster deprecation path and having someone who's willing to keep up with the budgeting. Any other points on this topic? Great. We already spoke about, Glamsterdam, DevNet 5 timelines, so… To summarize, is there any other Glamsterdam-related topic that we should discuss today? Yeah, Potuz?

Potuz: Yeah, I want to request again if clients can, ping me or give me images when you guys have implemented the honest reorg feature and dual deadlines for PTC. I want to start, actually checking fork choice. We haven't been testing fork choice on the DevNet. I need at least 3 clients that have dual deadlines that I can set at different times. And honest reorgs of late payloads. You don't really need the honest reorg of late payloads, that's not that important. I'm gonna take care of reorgan myself, but I do need dual deadlines.

Parithosh Jayanthi: Yeah, Barra.

Bharath Vedartham: Yeah, I just wanna ask, like, regarding the builder API stuff, like, what DevNet or something should we target that for? Like, do we wanna wait to make sure that Glamsterdam DevNets are, like, very stable, and then go for it, because I'm just curious, like. how we should be looking at that, because I think, for me, it makes sense that That can come with… when all the… the DevNets are stable and P2P bidding is, like, working well across all clients, and then this is something that can, like, be added after that. But I just want to get… understand, like, what do people think about that?

Parithosh Jayanthi: Is there a specific client or someone specific you would want input from, Bharat?

Bharath Vedartham: No one specific, like, just… I just want to get to a general understanding on, like. which DevNet, or when we should, like, probably, like, think of targeting them. Just, like, curious to know that.

Parithosh Jayanthi: I'd probably say DevNet 6, because DevNet 5 is mostly relaunch of DevNet 4 specs and focus on stability. So yeah, I think the type of things you're talking about will likely be relevant for DevNet 6.

Bharath Vedartham: Okay, cool, thank you.

Parithosh Jayanthi: Okay, one maybe other minor, point, we merged in a new tool called Disruptor. They should give us the ability to do short-range and long-range reorgs and network forks directly in Kurtosis, so if you want to test fork choice and trigger a lot of small reorgs regularly. Have a look at the playbook. Everything's just done by a sort of playbook, so it's very configurable and easy to… to reuse. If you have any questions about it, then please reach out. Yeah, Potuz.

Potuz: I wanted to ask a question to clients. There's a discussion on the chat about some possible fork-choice bug. I want to ask about how are you guys sending PTC attestations? It just occurred to me that it would be very rare to have a situation in DevNet in which the PTC voted for the payload being timely and the data being not available. So I'd like to have confirmation that clients are actually, making the right attestations. I think Prysm had about a lot of this, making the right attestation with regard to both timely and data available, and if they… clients… since we are getting these attestations very early, like, much earlier than the deadline, we're getting them together with the blog sometimes, I suspect that clients are sending these attestations

as soon as the payload is there, as soon as the payload is synced, I just want to make sure that we are sending them with the data available flag correctly set. I'm very surprised at what Nico is pointing out, that Lodestar might have been hit by a situation in which the PTC voted split. Timely, but not available.

Parithosh Jayanthi: Stefan said that Teku sets them on deadline, and if blobs have arrived by then, then they set the flag.

Nico Flaig: So for Lodestar, we only send them early if we see the block. So if we had the proposal ourselves, then we could send them really early.

Potuz: But… so only… so if you're not a proposer and you see the payload very early, do you wait until you put it in fork choice? So, namely, you wait until you're sure that the data is available?

Nico Flaig: And we only vote when everything is available, and we import the payload. Otherwise, we wait for the deadline.

Potuz: No, wait a second, you should… I mean, if the payload appears, is available, but you don't import it because… I'm sorry, the payload appeared, it's timely, but you don't import it in fork choice because you couldn't get the columns, you still should vote for available, timely, but not available. So, PTC attesters should attest to payloads that they haven't put in fork choice.

Nico Flaig: Yeah, I think that's what we should do, but I would need to double-check.

Potuz: That's actually very important, because if you wait until you put in fork choice, then you're waiting for execution as well.

Parithosh Jayanthi: Okay, any other comments here, or… Is there any conclusion, Potuz?

Potuz: Well, I'm not sure. We need to grab that block, and test Nico's theory. I'm very puzzled by this. I can't… I mean… I can only think of a bug if the situation happened that the PTC was split at this moment. In such a debit.

Parithosh Jayanthi: And… maybe 4K still has it saved. I'm sending the link. It's been running, so… Which could be there. Yeah, I think it's partly crashing 4K, it's not made for such crazy forking, I guess. Okay, anything else for Glamsterdam? Cool, then let's move to Hegota. The first item on the Hegota list is EIP7684, Return Deposits for Distinct Credentials. Do we have, Tapline or someone else to speak for this?

Greg K | Lido: Yeah, so, I had included this on the, last ACD call, agenda, together with the next one, like, 8148. But for the purpose of today's idea, I wanted just to, don't discuss on it, and move it to the next one, and discuss only for the second item, the 8148. because the topics are a bit unrelated, so I prefer to come, like, keep it focused, so… I would skip the first one for today and move it to the next call, and.

Parithosh Jayanthi: Okay.

Greg K | Lido: That's only for the 8148, if that's okay.

Parithosh Jayanthi: Okay, that's perfectly fine.

Greg K | Lido: Soon… Give me a second to share screen. So you see my screen, guys?

Parithosh Jayanthi: Yes, please go ahead.

Greg K | Lido: Okay, nice. So, I will try to keep it short, because this EIP was also discussed by Dima in a previous ACD call, just to, like, recap everything. So, it's EIP-8148, Custom Sweep Threshold for validators. It was also by Dima, Dmitri, and myself, who are all Lido contributors. And, it has to do with, the proof-of-stake, withdrawal credentials for validators. So, yeah, like, I think here for ACD call, we don't really need much background, but just as a reminder, what's the difference is, like, you have two validators, Alice and Bob, 01 and 02. The difference is that, when you, like, your effective balance exceeds 32 ETH, The 0x01 validators, the legacy ones, the rewards are automatically withdrawn every roughly one week from the automatic withdrawal algorithm, while 0x02 validators, this is not happening, the balance is compounding.

And, actually, the new threshold for 002 validators is 2048 ETH. So, there is this kind of asymmetry between 32 and, 2048, and nothing in between. So, yeah, fast comparison, like we all know, 002 validators can accumulate balance, while 001 cannot. They have both Minimum and maximum on 32 degrees. 002 validators require almost the same hardware resources per validator, but the important thing here is, like, 002 validators are better for the network, particularly to reduce total validator count. It was one of the main incentives to introduce in this class. And essentially, for fast finality, which is one of the most important parts of the future, roadmap, requires from 10x to 30x decrease on the number of validators to enable fast finality, together with other strawmap, elements. So, this is really where we need to go, and this is why, the goal of the protocol is to have validators switching to 002,

However, the main problem is that the adoption of this is slower than expected, although over the last few months, we had some improvements. So currently, I said this morning, this, from Bhuta, from June, like, 1.5% of validators are 002, and they hold roughly 28% of all is staked, because they have average of 821. And it has been quite discussed why is this adoption slow, and why people are not moving to 002, and one of the reasons is the liquidity concern. It's exactly this part that you don't get regular reward distribution with this automatic reward scheming as, in 001 case, that whatever goes above 32 ETH, you receive immediately, with no single actions required from the, like, from the validator.

And actually, that was the initial motivation of, the EIP, like, it was, like, during discussions in, Buenos Aires, like, in Devon last year, that this seems to be one of the big, barriers for many people to enter, 002. And, yeah, example of people that, were saying the same thing were, like, some small solo stakers, like, just 32 each stakers that they say, okay, I prefer to have this predictable has free rewards coming to me, and, but we had also serious, similar, cases with people who run, like, like, bigger, like, 6 validators, but… and the question is, like, why should I convert my 6 validators to 1 if I don't get my rewards automatically? Because I'm too far from the 2048 ETH. And similarly, there are also bigger players with just less than this, amount of ETH.

but they also prefer to receive the rewards automatically. And also, another class is fractional home stakers, like the ones that are using permissionless staking pools, like the CSM or ReptPool, that, they cannot afford bonds for full 002 keys, but so they prefer to stay 001 in order to be able to afford the bond and receive the rewards, for free, basically. So the solution, as you might predict, is to introduce a custom sweep threshold. So, instead of having the sweep threshold fixed at 2048 ETH. just make this a configurable constant for every 002 validator. So this is now… it would not be a universal constant, it will be just separate value for its validator, and when

The effective balance goes above the stress code, then the rewards will be sent automatically to the execution layer with raw credentials. So this achieves best of both worlds for this class of validators we've discussed, because they can set any desired amount of ETH to accumulate, so it's quite continuous, between 32 and 2048 ETH, depending on the profile of the validator. They receive any excess rewards automatically, and they can also change the threshold at any time. In terms of security, and, kind of protocol properties, it's designed in a way that it does not allow withdrawal gaming, so you cannot set the new threshold to be below your current balance, so it cannot be used as an excuse

to have faster withdrawals. So every validator, like, let's say if someone today has a thousand ETH, they cannot set the custom threshold below this, they cannot set above it. And the full control of the, of this threshold is to the stakeholder, so, it's only via execution layer triggerable actions that are introduced in Pectra, so the entity that contains… that owns the ETH, not the entity who runs the validator, can, can only change this script threshold. So, just to wrap up, what are the main benefits? First of all, for Ethereum protocol, the main benefit is that we expect that this will help reducing the validator count, which in turn enables fast finality, while not putting the smallest validators at this advantage.

And a second interesting feature that I think it's quite useful for the future of Ethereum Protocol is that this makes a potential future change of max effective balance, or even complete removal of max effective balance much easier. Because, currently, the way that the protocol is, in order to remove the maximum effective balance, you need to… modify also this sweep withdrawal algorithm. They interact quite heavily, but now, like with EIP-8148, this current constant of 2048 could be just used as the custom ceiling for current 002 validator. So, I think in the later part of the strawmap, there is an item which is called the preset, and it includes also, as far as I understand, removing the max EB, and I think this EIP

prepare the ground quite easily to make this future change much smoother, and which I think it's a good change for the Ethereum Proof of Stake. For validators, it allows flexibility, because a validator can become 002 and receive rewards at any desired threshold, so there are no kind of incentives to remain in 001, or trade-offs. And small stakers and fractional home stakers can remain into the game, without being at disadvantage. And one might ask, like, why, whether there is some impact on light as well. So, there will be some impact, but it's quite, small, and I just wanted to emphasize this. Like, 95% of Lido validators will switch to 002 anyways, no matter what happens with this EIP. You know, permissions, we already start the test network

migrations and, should be shipped until Q1. next year. And also, CSM, like, permissionless module for 002 validators will be, set by end of this year. But the point is that there might be a small fraction of the permissionless validators who cannot afford to bond for, for 2048. So, essentially, what this enables is the smaller players that are using Lido's permissionless staking to contribute to Ethereum decentralization. to keep them inside the game. So they could afford now a small bond, perhaps very slightly higher than now, become 002, and also don't kicked out in the future when the attester size gap comes, which is currently on Hegota of the protocol. So it's basically saving the kind of most decentralized 5%, which is vulnerable.

For the future, like, changes coming. And yeah, last, why check withizable timing, I think, is… I think it perfectly matches with the currently announced road map. I have a small screenshot on the related items. But the target is at Hegota, which is… which is expected to be one year after Hegota, essentially. The fast finality will become feasible with 100 gate validators, so it will give enough time to have one year between this feature gets enabled. And, the cap of number of validators being applied, so that both staking pools and validators have time to adjust, before getting kicked out due to this capping. And also, as I said before, there are other future big concerns improvements that exist on the strawmap, and this EIP is not so complex, and it will make those changes, which are here for the protocol easier to occur in the future.

So, this is it. Yeah, there is also a thread in the mathematicians, there is also a PR open for, including this EIP in the Hegota Meta EIP, and yeah, happy to take any questions.

Parithosh Jayanthi: Thank you. Maybe one question is, is there any argument against keeping today's ceiling and expecting 0x02 validators to just execute withdrawals manually? That's sort of hacking in the custom ceiling, right?

Greg K | Lido: Yeah, yeah, so if I understand the question, this is like, like, keep the current stuff, like, don't do the change that, I presented here, and just… Do the withdrawals via the execution layer, right? Exactly.

Parithosh Jayanthi: Exactly.

Greg K | Lido: Yeah, yeah. So, yeah, I think this is possible to happen, but the main point is to… maintain this seamless, reward accounting that, like, the reward received that happens today, with, this automatic, this is what I try to say, like, this automatic sweep, algorithm, like, it's predictable and custom-free, you don't have to take any action, the rewards come automatically to you. Yeah, that makes sense.

Parithosh Jayanthi: It is in the UX to have it automatic.

Greg K | Lido: you know.

Parithosh Jayanthi: Cw?

CW: Yeah, hi there. I'm Celtic Warrior, a solo staker that is reasonably well known on some of the discords, like ETH Staker. I'd like to come out strongly in support of EIP 8148 for all of the reasons that have been outlined. The number one differentiator between 0x01 and 0x02 is predictable cash flow. Staking income, whether you're a solo, small operator, or a large operator, is generally taxable, and that means that having predictable income for paying taxes, operating costs, sometimes living expenses. is very necessary beyond, you know, the tiniest operations, let's say. The challenge is, of course, that most solos don't have 2,048 ETH to stake. So therefore, we are kind of trapped a little bit in 0x01 because of the need for predictable, cash flow.

having a configurable cap, as suggested by EIP8148, makes all the sense in the world, and I could imagine, that most solo stakers, and this topic has come up a lot on the Discord, it's not new. I could imagine that most solo stakers would be quite willing to consolidate into 0x02 if this configurable cap was available. I should also point out that in my professional life, I work in digital assets in a financial institution. A large one, global. It also appears to me that a configurable cap would be very useful for institutional stakers as well, and why is that? Risk limits. Right now, with 2048 ETH per validator key, that's a $4 million key. That's a lot of value at stake in a single key.

even if an institution has hundreds of keys, it doesn't matter. It's still a lot of value at stake per key. It probably would be convenient for a lot of institutions to be able to say, look, I want to have a million dollars per key at risk, and still maintain predictable cash flow, or I want to have two million at risk, and still maintain predictable cash flow. So there's a myriad of different reasons to 8148 being implemented. Really what it is, is just an upgrade to 0x02. We should do that.

Parithosh Jayanthi: Thank you, yeah, Amir?

Amir | P2P.org: Yeah, hello, everyone. I'm Amir from P2P.org, we are a large node operator in the ecosystem. Just wanted to, show my support for this EIP, and some of the reasons that I see this as a need for both institutions and solar stakers, building on what CW said, and what Greg presented. Now, I, I think, A key point here is for the rewards not to be automatically added to the effective balance, so if we want to do partial withdrawals, even as a node operator, if we can, which we cannot. that would… that rewards would go through the withdrawal queue, and not directly to the street delay. So… and that kind of… That's not predictable, it depends on what withdrawal Q is at that time, but if someone wants, sort of, like, a dividend mechanism on their validators, they want to be… they want the cash flow to be predictable and be liquid for them, so they don't want to…

Have the risk of withdrawal queue being super large. So making it automatic and not added to the effective balance would solve that problem for them. Another key point is, us as a node operator, we do not have the access to withdrawal address, so we cannot initiate partial withdrawals on behalf of our clients, so it's an added operation on their side, so if they want to do something like a dividend stock mechanism for their customers if they're an intermediary, they need to add this operation internally, with the withdrawal queue, and from what we've seen, they much rather go with the 32 ETH validators at the moment, just not to have that headache, and not utilize 0x02 validators.

Parithosh Jayanthi: Thank you. So as far as I know, custom ceilings were something we were looking at during Pectra as well, but the main reason against it was implementation complexity. Perhaps there's some CLs who want to speak to it, or… Give your opinion on… on… on the EIP? Okay, other than that, it seems like there's some, comments on it as well. Essentially, if the threshold needs to be in the EL or on the CL side, like, client, do you want to maybe bring up the topic?

Lightclient (Matt Garnett): Sorry, I was just… I was just trying to understand the proposal. Bill, you… Want to write the… this threshold on the EL, and then the EL decides, given the… Like, potential sweeps when… The funds are dispersed to the validator? Is that my… is that the right understanding?

Greg K | Lido: No, no, this is on the CL. So, in the CL is where the withdrawals happen, right? So, what currently happens is that.

Lightclient (Matt Garnett): Like…

Greg K | Lido: Oh, it's a…

Lightclient (Matt Garnett): Sweep threshold request contract. That's just to register the… threshold?

Greg K | Lido: Yep.

Lightclient (Matt Garnett): Okay, so it is also written into… Registry on the consensus layer.

Greg K | Lido: Right.

Lightclient (Matt Garnett): Makes sense.

Greg K | Lido: Yes, I just think… there might be some questions, like, while talking… I saw there was some questions about max EB that I discussed, but I can't see it now. If someone can raise it, it would be fine.

Parithosh Jayanthi: Do you mean the point from Barnabas, where he was talking about, removing the max EB upper bound completely? So, essentially, everything's a custom ceiling?

Greg K | Lido: Yeah, yeah, this is actually what I think, like, it could be like that, right? But, yeah. But I'm not… I'm not sure when… people who want to remove this max effective balance, and why, like, I'm not, so it's outside the scope of this particular EIP, but I think it allows to do these things whenever we want it much easier.

Parithosh Jayanthi: Okay, any other comments on the EIP? If not, I think clients would need to look into it, look at the details, and then we bring it up again in the next call. Okay, thank you. And I think you said initially that we'll bring up EIP7684, In the next ACDC. If you want, we still have time at this ACDC to bring it up if, if you're already prepared for it.

Greg K | Lido: No, yeah, let's put it in the next one, yeah.

Parithosh Jayanthi: Okay, that's perfectly fine. Yeah, Tony had a comment about, simplifying the EIP. Essentially, no EL requests, transactions, just directly right into CL state. I think more devs also need to look at the EIP to figure out what the shape is, should be.

Greg K | Lido: Yeah, I'm not sure, about the question. Actually, I will share now the… also the EIP and the specs, we have, but the idea is that from the EL, the request is triggered by the owner of the stakeholder, the owner of the capital. From the CL, is, like, the node operator who runs, the validator, who has to do it. So the idea is, like, like, in delegated staking, the owner of the capital is the, like, on the execution layer, so… That's why we use the execution layer request. But I'm not sure if this is the question, so if there is something else, just let me know.

Parithosh Jayanthi: Tony, do you wanna immediately answer that? If not, Potuz? Okay, Potuz?

Potuz: Yeah, so I feel… I mean, I'm… overall, I like this, the EIP. I think it's not going to affect much the… The purpose of having 002 validators, which is to actually have large, effective balance, because we want to concentrate validators. And I feel we're not going to see many validators that are going to be in between, so it's… it's not a danger. But what I… what I feel is that we're conflating a couple of things, like, on the way pools work. I understand, for example, if I have a home validator, it's my own validator, and… and… and I… I can afford to have more than 32, much less than 2048, then I might want to have a limit around, like, say, 128 ETH.

And then consolidate everything on one validator. But what I don't understand is for validators like CSM operators or rocket pool operators, why would they need to be, running these validators with a custom limit, why… I mean, if the withdrawals are done… if the sweep is done on the pool itself, the pool has a lot of capital, they can actually be handling this on their side instead of, on the pooled capital, instead of, like, overloading the protocol for this. So I don't see how… so on… So for pools, I would have expected that the pools themselves can handle this without having to overload the protocol. And for homestakers, well, we're seeing homestakers anyways consolidating. So, yeah, so it's that.

Greg K | Lido: Yeah, so I'm not… So, but I think the reply to your question is that the bond that you have in the permissionless taking depends on this effective balance. So, the bond that you have when you have a 001 validator, and the amount staked, like, using the capital provided by users is 32 ETH, then the bond is something very small, like 1.5 ETH. the bond that you will need to, to use in order to run a permissionless validator when the, max effective balance is, like, 2048 will be much higher. So, basically, you cannot, like.

Potuz: Yeah, so, but it's… it's… it becomes… I mean, if those numbers are like that, I just contacted, actually, Jim on the side, because I wasn't excited about CSM accepting 002, but if the numbers are like that, then again, it becomes very, very niche, right? A very small operator for CSM, like, running 24 keys. would already have the full bond to stake at 2048 validator. So this only makes sense for a CSM operator that is running about between up to 12 keys maximum, so between 1 and 12 keys maximum. So I suspect that this is going to be very, very niche.

Greg K | Lido: Yeah, so, you mean from this, focusing on the set of CSM validators, and this is a small fraction of them, this is what you say, right?

Potuz: Well, I would have expected this to be, like, essentially no user of the chain to be on that, because… It's not the difference between 32 and 2048. Now it's the difference between having 1.5 ETH and 32 ETH. Right? Which is the bond. So…

Greg K | Lido: Exactly.

Potuz: The question is, how many operators do you see running keys for somewhere else, so semi-professionally now, at their home, running on metal validators, and bonded for much less than 32 ETH? And I don't expect that number to be a large number of validators. And those are the guys that are, according to this. argument will benefit from this EIP, On the pool side, of course, home stakers will, benefit, but on the pooling side, I only see this very small fraction.

Greg K | Lido: Yeah, correct. So, I don't have a precise number right now. So, I said before that 95% of Lido validators will be anyways there, even without the EIP. So, we expect to be max 5%, but it might be even less, but yeah, I don't have now an optimal, like, I don't have a precise number around that. Yeah, so 75% of… yeah, no, 75% of the 10% is basically… yeah, 7.5% has less of it, something like that. So it's something between, let's say, 5 and 7.5%.

Parithosh Jayanthi: So I guess the request here is a bit more data about how many validators this would actually help with consolidation, right?

Greg K | Lido: Yeah, but the question of what is, like, how many validators does it help? within the Lido side, not in general. So I think in general, Potuz agreed that it is useful for, like, small stakers, but the question is, like, what percentage of Permissionless taking pools. Who wouldn't be affected, right?

Parithosh Jayanthi: Yeah. Cw?

CW: Yeah, it would seem to me that there are three distinct categories of staker that should be considered here that could potentially benefit from the EIP. Number 1, solo stakers, with Smaller amount than 2048 ETH. Number two, pool stakers, and number three, as I said earlier, institutional stakers that want to be able to configure the amount of risk per key. Which could be very convenient, particularly for those institutions that have things called risk committees, which are reasonably common in the financial industry.

Parithosh Jayanthi: Yeah, yeah, thank you. I guess we continue the conversation in the next call. Is that okay for you guys? And maybe we'd add some more color onto the number of Lido stakers this would, affect, and it would be nice if client teams could have whoever looked into custom ceilings, during the Pectra implementation present on the call, too.

Greg K | Lido: Yep, I also see, actually, from Barnabas some comment about… consensus layer EIPs, from Glamsterdam, which I guess… Yeah. should have been discussed, like, before Hegota, but perhaps it's useful to discuss now, since we are still having some time.

Parithosh Jayanthi: Yeah, I just wanted to give ample time for Hegota discussions. Is there any other Hegota topic being proposed for today? If not, yes, we can bring up the Glamsterdam CFI, DFI decisions. Okay. Yeah, let's, jump back to Glamsterdam in that case, since we still have some time. First EIP that is still pending is, EIP8080. This is, let exits use the consolidation queue. So the intent here is mainly that, We still have a bunch of CFI EIPs, how serious are we about implementing it for Glamsterdam? If not, let's DFI them. Has anyone looked into exits using the consolidation queue?

I don't think Francesco is available today to present it again. Okay, maybe to be fair to client teams, we shouldn't make the decision here right now to DFI it, but at least give intent that we plan on DFI. Yeah, and…

Greg K | Lido: execute on that.

Parithosh Jayanthi: And decision in two weeks.

Greg K | Lido: Yeah, may I ask whether there is context on why to DFI this EIP?

Parithosh Jayanthi: Essentially, that we still are working on Stable Glamsterdam, and there's a bunch of other EIPs that feel more important than this one. So, if we're not intending to ship it in Glamsterdam, then it's better to earlier DFI it, so… It doesn't hang around at a dead state.

Greg K | Lido: Okay, but what is weird is, like, there is this difference between DFI'ing and DFI'ing with moving to Hegota, considered for inclusion, right? So… I guess if it's DFI'd due to timing, then it should be kind of… Automatically included power or not, I don't know.

Parithosh Jayanthi: Yeah, I think that's the part I would also need to check up. As far as I know, no, that isn't the case. It doesn't get automatically added to the Hegota CFI list. You would need to re-propose it for Hegota. Yeah, exactly. I think, Tony and Nix were kind of mirroring that. It would need to be re-proposed for Hegota. And the proposal for window for Hegota is still open, so it is better to make the DFI decision now, so people have ample time to re-propose. Okay, so for EIP 8080, there's intent to DFI it, we'll take another call on it at the… at the next ACDC, and make a decision.

The next one is, EIP8061, increase, exit, and consolidation churn. Do we have Anders, perhaps, on the call? Okay, Barnabas, you proposed SFI-ing this. Why… why is that, if we don't have this on DevNets yet?

Barnabas Busa: We do. We've been having this in DevNets, since DevNet 1.

Parithosh Jayanthi: Okay, perfect. Are there any clients against SFI-ing this in two weeks? Is there any reason that we would want to take this out of Glamsterdam? Potuz, EIP-8061, so this is, increasing exit and consolidation churn. And it creates a separate consolidation shown limit parameter. Yeah, exactly. It's already been implemented and tested, so the main argument is, if this someone making a case for taking it out. If not, then in two weeks we can SFI it. Okay, the next EIP is, EIP8045.

Excludes slashed validators from proposing. I don't think there's an implementation for this, right? Has any client looked into… implementation complexity for the EIP?

Potuz: I'm sorry, this is excluding from duties.

Barnabas Busa: So, just rampos up.

Parithosh Jayanthi: proposal, just proposal.

Potuz: Closers.

Barnabas Busa: It should be fairly easy with the proposal you could add.

Potuz: Yeah, I think… so in Glamsterdam, we discussed this, it sounds to me that it's absolutely trivial to do this on, just only for proposers, so I am inclined to… to accept if this is specified. It should be very easy for us to implement. I assume… I haven't really seen the details of the EIP, but I assume that it's just… at the time of computing the look-ahead, you just pick the next one if it's slashed. If it's that, then it's… this is a very simple, change.

Parithosh Jayanthi: Sure, but is there still intent to ship this, potentially, or not? If there's intent, then we can also leave it in SFI. If there's absolutely no intent to ship it, then we move it to DFI.

Potuz: I can have the PR open in presently, like, 5 minutes. It shouldn't be an issue.

Parithosh Jayanthi: Okay, then if you could do that, then we can take a call in two weeks, what we want to do with this EIP. Worst case, it stays in CFI mode until, it gets scheduled in a dead net. But yes, it would be nice to know if we're talking about a relatively trivial implementation or a much bigger one. Okay, the next one is EIP7688, Forward Compatible consensus Data Structures. This is a bigger EIP, for sure. the question is… and it has been CFI'd, the question is, do we… intend to ship this in Glamsterdam, or not at all? And push it to Hegota.

Or is there not enough information at this point? Have any client teams looked into rebasing 7688 changes? I know there was a DevNet in the past, but rebase on top of Gloas?

Barnabas Busa: the PR is currently rebased on top of Gloas. I think we are just waiting on a decision whether it's gonna be making it into the next, CL spectral is. Just a temporary comment on that.

Justin Traglia: Yeah, we're just waiting for a decision to be made.

Parithosh Jayanthi: Okay, since this is still a relatively large EIP, I would leave it as CFI. Let's see how long it takes for us to get to stable Glamsterdam before we're talking about Another relatively large change to the codebase.

Barnabas Busa: Yeah, I think we've been pushing this for… months now, this decision, and that's why I think it would be very good to have a clear signal for plantings, otherwise they will never dedicate time, Yeah, like Kingy just said, I'll send in the chat.

Parithosh Jayanthi: Yeah, but the thing is, we can't move it to SFI until there's a DevNet. We're not gonna change dev nets until we have stability, so it's kind of in limbo right now.

Barnabas Busa: Yeah, but, like, maybe we can show an intent to restify. And, like, how we have the intent to the FI, idiot.

Parithosh Jayanthi: I think DFI decisions are inherently easier because we… Can have relatively high conviction that we're not going to get to them. But SFI decisions really do need a DevNet, people implementing so that we don't SFI something that we're not sure of. Yeah, exactly, and Nixo's already shared the, requirements to be SFI'd, so if anything. I think we just need to… get Glamsterdam DevNet stable, and then schedule this for a future DevNet. Yeah, Tony?

Toni Wahrstätter: Yeah, could someone quickly remind me what was the main motivation behind this EIP? Because now we also have, like, this… Yeah, side motivation, that it solves the deposit contract stuff, but was the… was the original motivation, basically, that we keep, like, the proofs? Against the Biker root stable? Was that… Exactly.

Parithosh Jayanthi: So that, if we change stuff, we don't need to trigger, everyone in the ecosystem updating their contracts.

Toni Wahrstätter: Right. Yeah, this feels like very, low impact, and we're quite advanced in the fork, and it's not a small feature, so I would… Probably lean towards not doing it.

Barnabas Busa: I wouldn't say that it's a low impact. Maybe we… maybe we disagree on this.

Toni Wahrstätter: Do we have a number of how many people use the CL proofs? Because I remember the last time we checked, it was, like, a handful of people. And not saying that those are not important or anything, but… It's quite a trade-off to now include a big feature. like, if everything is done, and definites worked fine, then I won't be opposed to just don't want to delay it for additional CR features.

Parithosh Jayanthi: Yeah, let's maybe leave it at CFI for now, and see how long it takes for us to get stable dev nuts, and then we take a call. But yeah, we should make the decision before we close the, the Hegota proposal. times. Yeah, stable diagnostic for stable containers, exactly. Okay, any other EIPs worth discussing, or any other topics worth, discussing today?

Mario Havel: If I may, just to interject for a little bit of topic. We are preparing the next cohort of, EPF, the Protocol Fellowship. Just wanted to remind you guys about that, and invite you to submit, projects for the upcoming cohort if your team wants to, get some fellows to help with of some, some implementation, some prototyping, and so on, please feel free to reach out or submit, your idea by opening PR here, so… Yeah, we are starting in a couple of weeks, so just wanted to remind you all that there is this possibility, and there are some former fellows here, some former mentors, so just, yeah, hope to Get some more people. For the EPA this time. And, yeah, thank you.

Parithosh Jayanthi: Barnabas, do you want to talk about the change in time for ACDC?

Barnabas Busa: Yeah, sure. So… In the interrupt, there was quite some feedback, from people that have not been able to attend, many of the DCDC calls, that live in the Australia time zone region. They are probably not here now, to speak up, and We were just discussing whether this alternative time slot would work for most of the people that are here right now, and if there would be any opposition from moving the time slot from 1400 to 1100. So basically, 3 hours earlier than when the current times are. And this would be only for ACDC, but for ACDE.

Parithosh Jayanthi: Yeah, I think from the European time zone, it doesn't really make a big difference. It's mostly gonna affect the Pacific time zone US participants. Okay, I mean, there's still some discussion about we've tried in the past, etc, how do we want to proceed? I think we had a small internal vote with some CL teams, it's… Kind of 8 versus… 8 people prefer… The 3-hour earlier situ- call, 6 people don't really care, and 3 people prefer the European time zone, so it's not a massive variance or any reason to really change stuff.

Could we maybe flip this and get a strong commitment of who we would actually lose and who we would actually gain if we moved the time zone from the client teams? That would probably be the… Thing that's, yeah, that's most important. Maybe to lightclient's point, it… I mean, it doesn't have to be a permanent move, you can also try it for one or two calls, see if there's actually better engagement, and then move it back if we don't. And to Barnabas' point, I mean, Terrence is on vacation. So that's, yeah. Okay, should we try it out ad hoc for the next ACDC? See if more people actually show up, and how the engagement looks, and if not, we can move it. By default, it stays at the current time.

The new timing is 3 hours earlier, but this is just a trial timing for the next ACDC, number 180, I guess, yeah. And 181 onwards, it will stay at the existing timing until… unless we make a more permanent decision. To answer Jihoon's question, let's say this is just going to be for the next call, so just 180, purely so that it's easy to communicate. So, if you're extremely bullish on the earlier time zone, then please show up.

Potuz: So what's gonna be considered, like, a success if there's more turnout, or if we… I mean, if people come in and we fight more, do we consider that as a success or a failure?

Parithosh Jayanthi: I would consider that a success. If the ratio of me talking to everyone else talking goes up, then it's a failure.

Barnabas Busa: I mean… We have more Lighthouse people and more tech people on the call. I would call that a success, if we can achieve that without losing many more, client intubs.

Parithosh Jayanthi: Sure, yeah. Okay, any other topics for today? If not, Then, thank you, everyone, for coming. See you next time at the earlier time slot, 1100 UTC.

Toni Wahrstätter: Thanks, everyone. Bye-bye.

Parithosh Jayanthi: Thank you for coming. Bye.

Greg K | Lido: Thank you for being…

Oisín Kyne: Thanks.

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