Consensus Layer Meeting 189 [2026-10-15] | ACDC 189

GMT20261015 134530 Recording: hello everyone. welcome to ACDC number 189. This is issue 2247 in the PM repo. I dropped a link here in the chat to the agenda. So today should be another phone call. we'll touch on Glamsterdam. We just have the Sepholi fork and hoodies coming up. A few other things there. And then we'll continue with Hagota. Again, a couple things have come up, including, of course, scoping the fork. So let's go ahead and jump in. First up, Glamsterdam. And yeah, we had the Sepolio fork. Seems like it generally went pretty well. Anything anyone would like to add or point out about the fork? Yeah, time for Idi, says Brandomus in the chat. Generally, yeah, the fork went I think actually really well. And yeah, that's a good sign. So again, congrats everyone. It was, yeah, as always, it's a big lift to fork any network. So yeah, it was a big thing. We did this for Cepulia and it lined us up for yeah, the the next networks coming up. Which brings us to hoodie. so hoodie has been scheduled for October twenty-sixth, UTC time. And yeah, I think everyone's aware of this at this point. One thing I can ask for is client releases. I think only so far I've seen Lodestar and Etherex. I'm trying to keep an eye out. but yeah, one thing we'll do is put out blog posts from the EF, like we did for Tipolio. We'll do this for Hoodie. And yeah. That's pretty much ready to go. except for client releases. So I believe we set a deadline of tomorrow. so still a little time, but yeah, would anyone like to call out earliest they've made? Otherwise, yeah, I'll just keep an eye out for that. Barnabas here in the chat says one small note. okay, DevNet twelve. And okay, yeah, just testing builder deposits there with invalid deposits. Okay, thanks, Barnabas. let's see, Teku here says release tomorrow, Lighthouse says early next week. Okay. yeah, as soon as we get quorum of clients for the blog post, we'll go ahead and publish it. And then yeah, you know, we can always update it if someone's a day or two behind. But that being said, yeah, let's get them out as quickly as we can. Cause again, hoodie's pretty distributed testnet, so we will need yeah. People will need time to to update. Okay. Otherwise then yeah, Hoodie is on Rails moving forward. Anything else on Hoodie that we should touch on? we should actually test the builders being available at the fork transition. So I think we're going to need to make some deposits before the fork, probably some top up transactions, and then it would be nice to have the builders signed up and hopefully propose a first or the second slot already. Okay. it's a nice segue to the next topic. but before we get there, let me just actually make a note about that. Give me one second. Okay. yeah, good call, Barnabas. Thank you for pointing that out. okay, then yeah, so that'll be nice, yeah, just to kind of run through all the paces with possibilities of Clamsterdam. And like I said, that is a nice segue into the next topic here. So this is Dimitri. He Brought up this issue from the consumer specs that he wanted to discuss. yeah, this seems relevant to builder deposits here. is yeah, I'm here. Yeah, yeah. and happy to start. Yeah, so the issue is pretty simple and it has already been pre preliminary, let's call it this way, discussed in Ethereum R and D Discord. However I still want to have a broader discussion here and get to some sort of a consensus about this issue. So the core of the issue is the following. We have a pretty vulnerable valid initial validator deposit process that we're gonna talk about in a second when scoping EIPs. But you all know that the rule For the validator data to be set is that the first deposit wins. So whatever deposit is the first in the in the queue of the pending deposits sets the validator data, namely withdrawal credentials and stuff like that, once and for all. It cannot be changed later. And any further deposits within this deposit, everything but the validator public key and the deposit amount is ignored. So this the all of the other deposits are considered so-called top-ups. and for some reason, well, maybe was even sensible at the moment, the decision was made that this specific one-time builder onboarding would work in a similar way, though the outcome here is a little bit different. By the sim by similar way, I mean that if you have a single deposit in the deposit queue at the time of Glamsterdam Hard Fork. With with the draw credentials with the prefix of OXOB, which probably stands for builder, then any other deposits that are also in the deposit queue at the time of the hard work will be considered top-ups, but top-ups not for the validator, but for the builder. And the core of this issue is that it changes the way how this race works, because previously. There were two possible outcomes. So if you have a deposit within deposit within pending deposits, you can be 100% certain that your deposit will end up being validator, but yeah, end up being validator. And the only thing that might be different is the withdrawal credential. So if you lose the race to an attacker. then you get a validator with invalid withdrawal credentials. And upon this assumption, protocols like LIDO and I believe many other protocols have built their own protection systems so that if you if you can prove that after making deposit, this initial say one ETH pre-deposit, your validator appears on consensus layer with correct withdrawal credentials, then you're good to go and deposits can continue. If your validator appears with wrong withdrawal credentials, but with the same public key, then the other option for you is to prove that the deposit was invalid and discard it. The problem with this builder onboarding process is that as the result of this builder onboarding process, if you have any deposits which were made with validator prefix, not the builder prefix, but they They stand in the deposit queue after the deposit that is made for the builder, the final outcome will be that no validator would appear at all. Which means that current protection systems on the application layer for this very thin, like the single moment of a Glamsterdam hard fork might find themselves in the situation where they made a deposit. Expecting one of the outcomes, like expecting a definite outcome that the validator would appear with either correct or wrong withdrawal credentials, they now have the third outcome that they were not prepared for, which is no validator has appeared at all. And instead, the builder has appeared, and now their deposit is stolen by builder. So what we think from the like from the application layer perspective and fairness. to the application layer, would it be fair to do is instead of treating all of this other deposits with a validator prefix in within the withdrawal credentials, instead of crediting those deposits to the builder, credit them to the validator. Because as far as I remember, after Amsterdam Hard Fork, you what you can do is you can have the builder and the validator with the same public key. So no problem here at all. And the only thing we are proposing to change here. Is to keep the outcome the same. So if you ever made a deposit with validator withdrawal credentials prefix, you should expect and you should get a validator at the end of the day and not end up in a situation where you end up with nothing at all. And I hear the comments that okay, you can in like rebuild your proof system and expect this third outcome. but this sounds a little bit ridiculous to me from two points of view. The first one is building anything on the application layer, auditing and stuff like that for just a one-time thing looks like a little bit of an overkill. And the second thing that the fix is actually very simple and it would not affect builder experience at all. Because if you want to top up your builder later on, you can still do it with a legit deposit with the same prefix. So why why should we mishmash or intermix both deposits to validators and builders at this very particular moment, given the fact that after that, you would still be able to have a builder and validator with the same public key? So our proposal here is to fix this small issue, and the fix is also linked to to fix to this pack is also linked to the issue. It's a very small and pretty simple fix that would make life way easier for the majority for of the application layer protocols who rely on this pre-deposit mechanism for to secure their deposits. And it would wouldn't also be a major lift for core teams to make this small change. So that is pretty much it. Okay. Yeah. Thanks for bringing this up. I believe we talked about a similar issue in the past, if not the same thing. but yeah. that all being said, I hear you. It is also pretty late in the process, I think, to be changing things. unless, you know, there is some critical impact to the actual protocol security. and yeah, I'll just surface Some of the comments here essentially saying that yeah, you know, there are workarounds at the application layer. And while that might be inconvenient, I think given where we're at in this process, that seems to be I think the answer for now. And yeah, again, I don't know if any of the people in the chat that commented want to chime in. anyone else from the client team. Can I ask like any any anyone from the client teams to specifically say why you guys consider that making a really simple fix that again would not impact the experience at all, right now being too late while fixes on the application layer and workarounds on the application layer. And I wanna specifically stress that there are a lot of applications compared to just one base layer. And the fix on the application layer is orders of magnitude more complicated and then multiplied by the number of protocols who should fix that. Why do you guys think that it's indeed reasonable to say, hey, go and do like 10 or more, I don't know, 20, how how how how many fixes on the application layer instead of making this really simple change and maybe you can elaborate on why you believe that it's too late to change something, given that it's not a breaking change at all. It's just a change to a one time use function. Maybe I'm dumb and I'm missing something, but I really want to hear to someone from from the client desk. I'm kind of, but if this is a actual issue, it should have been raised like five, six months ago. And then we could have actually included this much, much earlier. But we already shipped this fork into Cepolia. We are about to schedule hoodie. Well, we have scheduled hoodie already. So you're basically asking us to make a fix in live production that is going to only apply on mainnet. Which is just not gonna happen. But we still have time, I guess, to to have it on hoodie. Again, the fix itself is very simple and it doesn't matter that much how Cipolia was delivered because again, this is a one time function. This is not a change to consensus. And I I I'm not even sure that this particular case was actually tested during the real Cipolia hard fork. And even if it was, it again, it would not change much. It's just a matter of How like which requests you pick from the pending deposits? Yeah, I mean, so I can just summarize the comments here. Essentially, yeah, so again, I hear what you're saying. Like you I don't think you're seeing something clearly other than the fact that, yeah, given where we at we're at in the deployment process, you know, I think the like proper thing to do in this scenario would be to, you know, if we were to make the change, we'd make the change. We'd probably then want to like fork Sopolia again somehow. Then hoodie, then mainnet, it pushes things back. And again, that's kind of what I meant earlier when I said, you know, if this was like some actual consensus issue, of course, then we would fix it. but given that it doesn't impact the security of mainnet, the protocol, I think it's hard to justify. And this is why all the client teams are chiming in. Yeah, also let me add from the security perspective of this issue, because we audited multiple approaches to solving this issue, like pre-deposit guarantee contract. We reviewed multiple approaches from different protocols who wants to solve that issue to work around it somehow. And everything looks too complicated and too logic loaded and everyone has to like monitor it how it goes to audit multiple off-chain services like signature based when you check the deposit route and you have to just adapt to like any changes in consensus layer so it looks like workaround which can be easier solved, in my opinion. Any other client teams want to chime in? I mean, one path forward here is I think this is maybe the first time people are aware of the scope and s impact of the issue from the application side. So what we could do is you know, give people today to look at this, think about it some more, have a breakout tomorrow, Friday, and make a call there. But yeah, it is it is late in the process. how does that sound to people? I tend to think that waiting or trying to make a decision later is not gonna change many minds. And while I do appreciate that there is complexities on somebody's plate, the truth is that, you know, we've already cut releases for Hootie and so have all the rest of the teams. And it feels like it would be just difficult in order to try to change course now. Okay. Barnabas. Just a quick question, whether this would be still a problem post post fork or this is just no like representative. This is the the Yeah, the the this issue only occurs at a single block, which is the first block of the new hard fork. Like the moment this function is executed, it's executed once. But then can't you just make no deposits? In that block. It's less about making no deposits in this block. It's more about having no such deposits within the whole pending deposits. And given the current entry queue, we cannot guarantee that it would be like exactly one block long. Right now it's twenty two days. And I hope that I I hope, I think, that this queue will not go down that much by the time we will have a hard fork. So the window would actually be not blocks. Maybe not even days, but rather weeks. Someone that audited the relevant code that Dima is referring to. it's very not trivial to deal with this from the on-chain perspective, besides just actually pausing this relevant part and the code for yeah as Dima said weeks, or like even to upgrade the code is not trivial at all to deal with this. It's completely new scheme of like how does the flow of the system works in the relevant code in Lido. I'm just reading the chat here. Yeah. Yeah, I mean this does seem to be the read that core developers want to just stick to the schedule right now. It would involve, yeah, like there's more risk if we were to change hoodie and mainnet and not have, you know, another shot on goal of Sopolia. Also again, yeah, just given the timing, it seems like people prefer just to keep things as they are. Are there any core developers who are interested in exploring this further? Okay. yeah. Okay. I also think in the interest of time we should time box this. But yeah. Doesn't sound like there's appetite for a change right now. yeah, but I hear you in terms of the impacts. I'm yeah, I'll I'll I can try to reach out and see what what's possible, but I'm not sure. It sounds like you've done all the light work already. So yeah, again, unless anybody wants to explore this further, let's go ahead ahead and say that we leave things as they are. And yeah, that'll be that. Again, Dima, thank you for bringing this up and yeah, all the work that everyone put into analyzing the fixes here. Okay, let's move on then. any other final comments for Glamsterdam? Okay. Then we'll move to Eggata. so yeah, the main thing today is just to continue the scoping process. first up though, we Barnabas at least wanted to bring up an issue or at least yeah, proposal here with an EIP we've already CFI'd 8365. Barnabas, would you like to say some things about your comments on the agenda? yeah sure. So eight three sixty five is basically disabling new zero zero zero validators and as the EIP describes it right now, those that would still make a deposit after the after the fork they they would get all that ETH burnt basically. And I I kinda disagree with that. Like I I agree that we need to stop zero zero zero validators, but mistakes can still be made. So I I think it would be better if we would still allow those validators to join, just basically have no validator duties and they could basically earn nothing if they do decide to join. They could still do a BLS change, they could still make an exit, but they would not They would not do the validator duties. And as soon as they would do a BLS change, then the balance would get requeued and it would be basically handled as a part of a new deposit. So this way we cannot have an attack basically on the network where there would be a bunch of 0x00 validator keys being made and then suddenly all of them would change to 0x01. And we would get a huge inflow of ETH onto the chain. Okay, thanks. has anyone else had time to look into this in terms of this is very recent, so I yeah. I wouldn't expect anyone to have taken it possibly. Okay. yeah, then I guess the ask today is just to say you'd like to update the IP with this. And yeah, I suppose from here people can take another week just to look at changes. I did spend a couple minutes looking through it. And I have some initial opinion, but I haven't fully formed my opinion yet. But why would burning ETH be bad? Because for example, like if you submit a deposit with an invalid signature, the ETH is burned. And it could be a user error, it could be a user using a wrong tool. And the same argument can be applied. to submitting 0x00 deposits in Hagoda, why would we have sympathy to those OX00 scenario? And we don't have sympathy for those who submitted with an invalid signature. Not only invalid signature, but like like deposit and withdrawal and all that, there's just so many things that can go wrong. And if something goes wrong, people can potentially lose money. I don't see why we need to make a special case just for this. So you could make a deposit with zero Xero Zero in Agata for example or in glass and you would have a pending queue of let's say sixty days and within forty days we would have a hard fork and in twenty days after the fork you would have thirty two burnt eight. So you could You could possibly make a deposit where it was still allowed, and then you go into a fork because of the long deposit queue and you would get your teeth burned. Okay. Yes, I do agree with this point. I think I I asked this open question on Ethereum Magician a while ago, but nobody answered. But I think essentially what we want here is to grandfather. those zero zero zero deposits that was submitted before the has it fork. And I I thought about this and I think the easiest solution here is instead of guarding the apply pending deposits, we just guard move the guard over to process deposit request so that it happens so that it guards when you submit the request, not when the protocol is trying to process the deposit. I think that we saw the the case that you're describing. But i if the deposit is submitted after H fork is aggravated, then I have no sympathy for for this case. Okay. Yeah. thank you both for that. Let's keep things moving. But yeah, I think the ask for now is just yeah to take a look at these changes. And yeah, I think we can just bring this back up in another call or two. yeah. Then we can hammer out if we want to change this EIP or not. Sound good to everyone? Okay. Then from there, next topic is to continue scoping of the PFID EIPs. Let me share forecast again, because that's been very helpful. Just to give everyone a view on things. let's see. Sorry, I'm just making sure I get this sorted. And I can't see the window. Okay. And then usually people want this a little bigger. Does that look good to everyone? Yep. Okay, thanks. Okay, cool. let's see here. So this is filtered for C E IPs that are still in PFI stage. And if we do that, then this should be the list that we have. in terms of jumping in, we had started discussing 8025 optional execution pierce at the very end of the last call. but had just started the conversation. I think that seems like a good place to just go ahead and wrap up the conversation there. That we started last call. is Ignacio here. I believe he wanted to share just a couple slides. yes and we can get back into this. Okay. I think I need to stop sharing and then you can share. Cool. I will share my screen. can you see my screen? Yep, I can. Cool. yeah, I want to make this very short because yeah, we have to discuss many other things, but we just wanted to do a refresher and directly address some of the points that were raised in the last call. So as a refresher, what AT25 is trying to do is basically allowing opt-in proven execution proofs into the network, and opt-in nodes to verify them, to collect metrics, and start having more understanding of how this would work, would would work in the network. An important point that we keep stressing is that every validator keeps re-executing the payload and testing as exactly as they do today. the EAP is very clear that they are not allowed to make proofs interfere or influence attestation pipeline in any kind of shape or form. This is a feature that is off by default. So even for notaers, they won't be pulling these proofs or something like that. Only non-attestors that are interested in helping collecting metrics and understand networking implications can really obtain on QDs. So, what we are mainly asking for for this optional network feature is basically allocating some resources within the CoreDev community, mostly on the spec side, or I would say on the EL spec side. so we want them to review and upstream and mostly this open PR, which has all the changes for E25 in the execution specs. On the CL spec side, the changes are already upstream as a feature. So we are in pretty good shape on that on that front. And on the right hand side of this first slide, we have some summary of readiness on EL, CLs and guest programs. On the EL side, we have already six of them integrated into our hype dashboard. EL clients are main responsibility within the CIP is basically implementing execution witness generation, which is basically the information the proven needs for proving. And six of them are already passing all the tests, or over 95% of the tests. And all these changes are already upstream into the main branch, which is awesome. so we are in a really good shape there. On the CL side, we have already iHubs upstream the changes into the main branch. We have Prism already with an open VR based on GlamSolam. And we have draft VRs in the RCLs. And on the guest program side and CG VMs, we have multiple combinations of integrations. This is not like blocking for AT25, but there's really good progress on that front. If you want to know More details about this, you can look at the Hive Dash or yourself. I will share the slides later. And also this progress MD file that we have where we track things in more detail. So why we want to shoot CFI 8025 in Hevata, if this is like an optional protocol feature, I think this is the main question that people might have in their heads. And I would say it comes from two main directions. The first one is having operational experience on how this change will affect the network and giving people some resource, giving like being clear about some minimal resource allocation in some teams to really get more into this and gain experience. I would mainly say on the east panda out side. to help us understand how this will affect the network or which are like the unknown unknowns that we should still discover. but the I mean we can do this anyway without CFI DIP, but the strongest argument here is mainly on the development and efficiency of the protocol. the AT25 PR on the execution spec is pretty big, it's like 16k lines. But on the right hand side I put a table where it really the aggregate is number because my sound a bit scary. only 65 lines are really touching the STF code, which is the maybe the most sensitive part of the spec. Most of the PR are mainly testing framework changes or tests for AT twenty five, which we have a lot. CI changes and unit tests and things like that. All these kind of changes are not really like don't have really a stable API within the testing framework. So we are always like one weird PR away from having a lot of conflicts. And it's kind of a decent amount of work to really maintain this. this is a PR that we have been maintaining for quite a while. at least for for for a for for a year and has been rebased on top of at least five dev nets in glamsterdam. so it's not really like a one-shotted PR or something like that. A lot of people have been refining many angles of it from EL and C L uhs. And these 56 line changes I think is really important to stress Because the main point here is that we don't want the CAP to really clash with other EIPs that may get scheduled for Heota. So it shouldn't really interfere with other efforts in in the fork. And the the other main thing that we want to stress is Proving blocks might have some we we might want to do more experimentation on how proving blocks interact with other upcoming changes, such as PVT. And PVT already has its own branch in the execution specs. We already have our own branch of eighty twenty five. they might be based on different base branches, and if we want to understand the implication of both being live, we'll have to maintain a third branch. And the same will happen with other things. If we are if we have the conviction that proving blocks in L1 will be something that will happen in the future, it would simplify a lot to really upstream our work that we feel is pretty mature and the steel team has been tracking for a while. And simplify all the coordination that comes from. creating all these branches because now core dev coordination is really the bottleneck for protocol development, not really like execution of the changes. And this will also simplify some pipelining or releases, such as releasing stateless block execution within the main releases from steel. And we won't have like this Lagging with between like AT25, let's say CGVM releases and main releases, and there's a lot of things that will be more efficient. on the last slide, I want to target some particular comments that we had in the last call, which were mainly why this should be a core EIP compared to an informational one or an ERC. my my angle to this question is that we want to make sure that at the protocol level we make clear that no CL is allowed to use proofs for a testation because this is not safe. if we put the CIP in an informational one or somehow in an ERC, as someone suggested, I think this is like a strong rule that we are putting in the protocol. so I I I see this as It's much safer that as a community we decide to be really clear about this rule so we can keep moving forward with spec development without putting the network at risk. And we have some clear rules about what CL should implement for the main releases. And I know that some people, because I've been talking with them the last days, think, okay, what if someone Changes the source code of CLs to a test with proofs. I mean, my answer to this is that they can already change the source code to a test whatever they want, and drop ELs or accept proofs in new gossip channels. So the main assumption that we always have is that CLs and network operators are following the protocol rules. That's an assumption that we have. And if someone wants to simply drop a EL, they can already do that by. Editing their CL source code and simply always attesting yes and 99% of the time they will be right. So I think it's important to set up the rules at the protocol level and force the implementation to follow the rules and because this is like our main assumption. And as a last point, some random questions. if we need repricing for AT twenty five, that is not the case because Proofs are not really required for a testation, as we clarified before. So repricing is more on the mandatory proofs side of the story. So in the into the future. And regarding picking CGBMs, or guest programs, again, this is not something for AD25, this is more for mandatory proofs. The execution spec changes are mainly how to correctly define a stateless block validation. With the right rules, with the right checks, and standardizing things so people have a coordination point to really do the work and and move forward. So that's everything I wanted to share and I'm happy to receive any questions. Okay, thank you. yeah, just process point, let's try to time box this. just so we have room for other things. But yeah, that was a really nice overview. thank you for that. There has been some discussion in the chat already. Just yeah, so I think, you know, well, at least summarizing the chat here, like the question is just like You know, do we need to CFI this versus is there some other way to get the you know R and D work that you were just calling out without that? any client teams want to yeah, go ahead. Yeah, I just want to say that the the main interest from our side is to upstream this into the specs. the steel team has a pretty reasonable rule of requiring changes to be CFI to be really upstream. and we try to simply honor on this rule because this rule is there for a reason for them, because if not a lot of people will be upstreaming really experimental changes. So we are trying to follow the the process rules and and honor the the way they work. that's kind of our take on why we need to see a f I D speak instead of simply keep working in parallel. Yeah, I see. I kind of agree with here that our process is not great in when we have this long running initiatives like block proving or binary trees or other things to integrate them in so this is the this is being tried to see if I d to to to integrate them better also, but we could potentially come up with some process of this more experimental features that are long running to try to integrate them better instead of leaving them in this merge hell and interaction hell web that that's hard to untangle and discover everything. So we can consider trying to tackle this instead of CFIing also, but CFIing is simpler with the current process. Yeah. I don't know enough about how Eels is set up on this point, but I do wonder if you know, rather than a branch of this, 'cause I assume there's a, you know, branch that has this code already in the Eels spec. maybe something like a feature flag or something like that. I'm just kind of brainstorming. that being said, it'd be good to hear from some CL teams. yeah. What their stance is here. If we go actually I guess I can reshare the forecast screen. But yeah, if any CL teams want to chime in while I'm doing that. Okay, I lost the chat now. Are there any CLTMs that want to chime in on this? I pulled up forecast here because yeah, going by client rankings, it's pretty mixed. Okay. At least they're calling here from Lighthouse, you know, they obviously support the work, but not so sure on CFI. I think that well I mean it's something that people want, I think, in in some sense, but my main concern is actually the scope. I I mean I'm happy to include that later in the process, if we see that there is room for that. So I mean at at the moment the the scope of fossil and essentially the scope of fossil is the main finger that is blocking me to to CFI this. Anybody else? Yeah, I mean personally I'm here with Lukash, like I think this could go either way in terms of CFI or not, but we have this process point around actually making sure the work does get done if it's not CFI. So yeah, this one's a little tricky. Any other CL teams or EL teams that haven't chimed in yet? Yeah, I mean I've kind of said in the c comments I don't really support CFI in this. I think all of these other large projects in Ethereum have gone through the same process of waiting until they're actually getting CFI to be included as a feature of Ethereum and have had to work in parallel or on their own branches for many years. And I don't think that we should now be changing this just to support. to optionalist or an optional feature. Yeah, you're on your hands up. Thanks. Yeah. on the truck side, we support moving AD25 to CFI for Hyota. the CKAVM roadmap requires substantial integration and testing work, and we need early commitments from client teams to give that work enough time. this was already told by Ignacio, but thinking that this could be an optional EP because it's an optional feature is kind of a misinterpretation of its purpose. the feature should be optional for node operators and improvers, but this its support should be an expectation for all clients. Operators should be able to opt in regardless of their client choice. That requires team to commit to implementing, testing, and maintaining this. I was going to talk about the support the CIP already has in the code, but Orna Ignacy already shared. I will share the the dashboard again, the hype tests that are running this on the EL side. Almost every client supports this and almost everyone is passing all the tests. I think that the more groundwork we lay now through AD twenty-five, the more we can focus our efforts on the unknown unknowns for mandatory proofs. and yeah, we've been supporting this feature from the very beginning. and we We want to see it CFI. Even though this is a CL team client decision, it would be great to also maybe include execution client decisions on this. I understand this point that any operator should be able to opt into this regardless of their client. That to me feels like a much broader scope than what even Ignacio was proposing. This is an optional feature that we are trying to test out to see if it is feasible on mainnet. I definitely don't think that any operator should be able to s choose that. Yeah, I I would say that we should focus more on the process here and the the the proposal is to CFI the EIP and we can later decide to DFI it if we think it's not convincing or something like that. I mean all the rules for being CFI are already ready. We have the spec branch in execute in the execution specs has been maintained for a pretty long time. A lot of people are already working on this. We have the safety guard rails to not really put the network at risk. And the main thing we want to do is to upstream work that is already quite mature and is aligned with the original vision of Ethereum. If we have conviction that this is something that we will do in the future, it's just making our process much more efficient and not really waste time on keeping a lot of branches when we also have a lot of our important work to do. regarding PQ or other things in the near future. So it's very would be really sad and and inefficient and when wasting scale resources we have trying maintain all this stuff when it's ready to be upstream. there's just not a good reason to make a EIP a core EIP past governance because the branches are difficult to manage. Right, but who is managing that? It's like basically me and steel team, right? Doesn't mean it's that still doesn't mean it's a good reason to push an EIP through the process. Every other large feature of Ethereum has had to deal with this for years on on end. Did we have a bit different process? Like maybe. But I don't think that this is a good reason to do this. Yeah, I mean I disagree. I disagree on that in the sense that that might be I mean, of course you disagree, you're the one who has to rebase it. But it's not about me, it's about like the resources that we have to do all the changes that we want for Ethereum, right? It's never been easier to rebase features. Like two years ago, maybe it was a different argument, but like now just ask Claude, rebase the feature. Ten minutes later it's rebased. So it's not about rebase, it's it's about like complexity of how PAPs interact with each other. So it's okay, no, that's different. That's a very different argument. But it's not now we have to constrain ourselves, we have to potentially constrain ourselves based on an optional EAP. That's a totally different argument than you were making. And I think that that's like way overstepping what this should what we should be accepting right now. In terms of the other EIPs we should touch on today, I think we should go ahead and make a call on this and then move on to others. What I'm hearing is that yeah, in terms of this being a CL EIP from the CL clients here today, yeah, it doesn't seem like there's support to CFI this. That being said, I do think you know we can at least have a verbal commitment today to. put resources on this just to put attention on it and keep it moving forward. But yeah, I'm not really hearing any CL team chime in that they want to go ahead and CFI this. Now is your chance to speak up. If you feel differently. Yeah, many from Prism team. So actually in our ranking, we said we did not write a big priority for this because this EIP yes does not require hard work. Yes, that's why the main reason. Yes, lighthouse has made the CIP in in in in unstable and Prism has a branch. And so CF or not this EIP would not make a big difference about the the effort we we we deploy to to work on this on this EIP. because yes it's optional. So in my opinion we could CFI it. And so it will kind of show that the yes, at least a s few few clients team are keen on working on this on this VIP. and just a comment on on the optionality because make it weird to me. So okay then the optionality is around consuming the the proofs but it seems there there there there is a gossip net gossip subnet now that is required by this. It means that All the nodes should support and in helping disseminating the proof and then decide optionality to use the proof or not. But if this goes in anyway, I believe all the types must support the the new the new cells, the new topic and and support the dissemination of the proof. So I mean the optionality is not complete. I I mean I don't know if it's time to to enter into Too much technical details here, but no, it's not true. I mean if a node should opt in with this AIP, he just exposed a e proof field in in its node record, ENR, and that's it. And you know, other peer wanted to to use as proof just have to to to look for peers in the network with this with this e-proof in r field and then the peer will know that other peers will subscribe to the exection approach. So yeah. Okay. So it's so it's optional also into participating in the networking laying. Yes, exactly. Exactly. Yeah. Okay. Okay. So maybe now a bit stronger support from Prism, but otherwise I'm not hearing it from the other clients. And I think there have been a number of comments in the chat from CL teams slash persons that they don't see the CFI. I mean I I don't know if there is some Lighthouse people here, but Lighthouse already merge into the unstable branch CIP. So it's for me it's an implicit support to it. A w why you would we want to to merge in in your encyclopedia branch if you don't support the AP? It does not make sense. Yes, s said otherwise who is against it, yes, as Ignac Ignacio asked in the chat. PUTUS. I'm assuming on Rico your hand was from earlier. Enrico was up for an in earlier. I am against this if this means merging into HESE. I'm sure that Manus Manus branch can be merged and will be merged into Presence Trunk branch. This will be a feature that we will maintain. I am against merging this into the main fork branch because then it means that this goes away from being optional and it would affect every single fork and every single work that we do. And then we are actually forced to not this maintainer, this branch maintainers forced to rebase into what our for our forks are, but every single EIP writer for the CL spec needs to be compatible with whatever this branch does. and this affects every single every every next fork. I think this this should not be happening for optional features. Rajasco. wanted to touch on the interplay of this EIP in regards to the specs. So the the the execution proof handler is very isolated and you know we we do introduce a proof comp proof engine but it doesn't have you know a lot of interplay with the rest of the specs so i'd argue that the argument around kind of considerations may not necessarily be that significant but you know, I'd encourage kind of CL devs to to to review that and come to a conclusion themselves. But that's my my personal opinion, as at least it's is quite isolated. And that was done you know, that the design was intentionally isolated to prevent kind of complications of that nature. we've actually done a number of iterations to reduce the footprint of this EIP to make this more kind of maintainable. We're not putting a burden on debt. Yeah. Thanks for the comments. yeah, that's all helpful, but yeah, it just seems like there's not consensus here amongst the SEAL teams to merge this in for this work. So I my read is that people would support DFI. obviously there's these caveats around yeah, the process here and how we work with this thing. It sounds like maybe there's something we could do in the eels. repo itself to make the work a little bit simpler. so we should definitely explore that. But yeah, as of today in terms of scoping, this seems like a DFI. Okay, Mario, last comment. Yeah, sorry. yeah, basically just want to echo the exact same problem that POTUS is having with merging into main is the is exactly the same that we're having today on the EL specs. Basically when you merge something onto the main branch, you're asking the rest of the EIPs to adhere to the to what's already merged, in this case CK EBM proofs. So that's what I wanted to get from today, the signal that this is important. We have to accommodate for it, right? And that's my concern of merging, just just merging into into into the main development branch. I don't want this to be like enshrined if the EL devs or the C L devs are not in favor of it. So yeah, that's that's my concern, right? Basically. Thank you. Yeah, thanks. again, yeah, I'm not as familiar with the EL specs. On the C L specs, we have this notion of like feature specs that kind of sit alongside the canonical specs, let's say, or main mainline specs. yeah. Either way, hopefully there's something we can do there just to make the the the know the actual engineering easier. But again, in terms of today, I think we go with DFI for this. And move forward. Let's do that. Okay. let's see here. We have about a little under thirty minutes, so One option here is to start from the bottom here, just in terms of how these are ranked, and try to get through things that we might try to think are DFI. just based on the client rankings. That I think will help us just move through some EPs. And then yeah, we're ultimately gonna have yeah, more IPs to get through, I think, probably on the next call. So let's do that next. then in that case, so yeah, we have this EIP here for VOPs. we had touched on it previously that it's informational. I think we can just set it aside for now. Then let's see what we can do here with the time remaining. we'll start with Rodos here. Let's see. Yeah, Chopper here is the champion. I don't know if you'd like to say anything briefly on this. Yep. Yep. Are you on the call? Okay. Yeah, go for it. Yeah, so I just have smells. There's definitely an echo. Some technical problems. should be good. Yeah. So Lodas has the goal of fixing pass design decision that we made when we introduced BuildAs. it's planning to fix two things. one is the access CPU load that we have on On large nodes, and the other one is the reliance on these notes. I think it's quite important to fix this, but I can accept that it's not for everyone. I wouldn't go by the argument that we don't have anyway drops today, so we should not invest in in this. what I wanted to say is that it does have a B option, a reduced version. which is fixing only one of these problems, which is fixing only the the one which is the access CP usage. So the mechanism is based on on an duty allocation basically. And we could do that and that's very simple. So that is this B variant if if the people feel that the the other one is too complex. although that's what I'm more passionate about about which we we just don't don't rely as a protocol on on those entities. Anyway, there is this B variant, which is which is very simple, and it's just simply putting into protocol what clients are trying to do on their own in different ways, but there is no synchronization behind it. And this would just allow us to to distribute the the load in the network in a simple way and just distribute the the load, the construction load if it would happen that we have more blobs in the next whatever number of months. until we arrive to Hagota. I have published some design notes next to it, so feel free to to go through those. if you feel like you still want to consider, then I'm happy to delay. but I see the score, so it depends on on who is up to it. Hey, thanks. yeah, any client teams want to speak to this? My yeah. My B the was keeping. my speedfot is muted, so I didn't hear I didn't hear the responses if there were responses. I don't think there's been any yet. Yeah. but yeah, just going off of this, yeah, didn't it hear from Lodestar Prism according to forecast here, Nimbus was in favor, but otherwise, yeah, Teku Lighthouse, Grandine. I mean against any clients want to chime in with any more color right now? The the main argument I've seen is that we don't have blobs. Yeah. I'm not sure that time in the following many months, but I don't know that I mean again, going off the client ratings, I think we go ahead and say DFI this for today. but yeah, I mean this is the type of thing where it's like I think we need to have the work ready to go. But again, yeah, like you're saying, just in terms of where supply and demand above are at today, this isn't doesn't feel like the most urgent DIP. Okay. Any other CL teams want to chime in here? Otherwise we'll just go with D F I. Thanks, Chabla. next up we have 8359. This is Beacon Block reporting field. And the champion was Hani Abu. Are they here or is one of the authors here that would like to say something brief about this? Hani Abu isn't here as far as I know, but I can say a few words. So this is the new proposed beacon block field, aimed to give us more data about client diversity on the network. The the that's the problem it solves is the current graffiti way isn't perfectly fitted for the more complex setups, like multi-node setups with different client pairs. So here we propose to add a new field to the beacon block, which would properly give us that information. it would be possible to opt out of this if anybody doesn't want to share that information, but the default would be to provide that. the main criticism this EIP has gotten is that we should just do this in the graffiti field, like we do today, which is okay, but the problem with that is that the graffiti field is used for other purposes as well. So some people just for that reason won't want to use that field for client usage data. So Just using the graffiti fields for this purpose will hurt adoption. of this kind of reporting. yeah. Adding a new field to the block is a very cheap way to get this kind of data for the whole network. yeah. So if we want to properly measure client diversity accounting for multi node setups and DVT, then I think this is one of the easiest and cheapest ways to do this. Okay, thanks. yeah, any client teams have questions or response to that. again, going off the rankings that we've already assembled, it's not rated super highly. yeah, again, I think we all agree the topic is important. I'm not sure there's support for this in Agoda right now. Any client teams want to speak up in favor of this? Otherwise we'll just DFI. Okay going once. I mean there is there is some comments here in the chat, but Paul I think was also an author, so I hope that he'd be in favor. Okay. Then let's defy this. but yeah, thank you for that. Okay. next up then we have 7716. this is anti-correlation attestation penalties. Again, not yeah. okay. I think my mouse just died. sorry about that. but yeah, go ahead. I was gonna see who the champion was. But yeah, go ahead. If you want to see something. I'm champing and and would share a screen if we get permission, but I think I was declined. this EIP is a proposal to add an increase to inactivity penalties the more people are offline. We already have this with slashing. It's meant to kind of disincentivize centralization centralization, but we've never seen a correlated slashing penalty live on mainnet. this EIP is relatively mild in terms of what it Does it increase the inactivity penalty by a max of 256? And there's a rolling average that means it's kind of bounded in terms of how long it can stay increased for. I'll drop a link in the chat to a calculator so people can kind of give it a feel and see the FAQs and stuff. The you know main arguments in opposition to it for the most part has been either like let's just do PQ, I want to DFI everything that's not post quantum. Or Teku expressed a little bit of hesitance to touch Beacon State. It is just adding one extra integer there, but they were like, Beacon State is, you know, not super fun to touch. but generally speaking, I think people are warm to the idea of encouraging decentralization, but it's more of a question of like getting beyond B tier or something of the sort. So my hope and ask for people today is that they say, like, yeah, I get that we're not jumping at the bit to kind of, you know. put in an S SFI, but let's, you know, leave it as CFI for the coming weeks and see how we get along through the fork and say, okay, yeah, this is probably worth it. The EF are also gonna like put out some stuff about crops and and things like that. The problem, Barnabas, is that we have probably some of the worst client centralization on the network since the kind of last five years of proof of stake. We've, I think, three different clients that if they fail will cause a liveness issue. And if they fail together, like in Hood or in Holski, We could have the worst case scenario of like, you know, the whole thing is screwed. But if we have liveness penalties, the idea is that will push people to take in more of this like longer tail clients and not be so overexposed to the most popular ones. It also impacts for like hardware too, of not being all in the same data center. We have five to ten percent of the network in OVH and Hetzner in certain data centers. So this would discourage that whenever they have liveness issues, which is occasional. Yeah, thanks. you mentioned slides. If you could keep it to like two minutes. I think I just have to stop sharing here. Yeah. Okay. But yeah, let's just be mindful of the time. we'll do. Can people see this? I can, yeah. Sweet. Okay, I won't show too long. This is the one you can mess with what clients you are. a common question is well, what if I recover more slowly than like kind of the enterprises that can recover faster? How the CIP works is once you come back under the moving average, you go back to normal penalties. So what that means for a slow responder is, you know, the longer you take to return, more likely it is you're close to today's rules. So relatively speaking, you know, it's it's actually more favorable to, you know, the small and solo stakers versus the others. And this is kind of the main reason why. It's if we, you know, turn up the liveness penalties, we go from the tiny blue dot you barely can't see to the orange dot in terms of penalties. And it's meant to discourage the slashing outcome, which would be, you know, pretty catastrophic even if we are up to 10, 20% of stake. On the last kind of four major liveness bugs we had, it doesn't do a whole load. It like changed your amount of hours to earn back what you missed to kind of twenty hours to four days. And this talks a bit about what clients can fail and the total slashing, you know, how it works for solo stakers, FAQ, etc. Okay. Thanks. yeah, and this is the link that you put here in the chat. So yeah, thank you for the overview there. any client teams want to speak in favor of this? I could put the forecast page back up, but ultimately it was not rated super well. So I think that would lean DFI for Hagota. Any client teams want to add any color? I would say got an S tier from Eeth Rex and actually all of the smaller clients have a bit of incentive to be more in favor of it because it, you know, hurts them less. Yeah, that's helpful, although E directs won't be implementing the EIP. So no, fair. It's more of a as for implementation, it is it is just like one variable in state and then the one pass through the validator list every epoch to figure out, you know, if we're above or below the moving average, so as to whether or not to scale the penalty. The EF protocol team kind of originally deified it by saying it touch slashing, which it didn't. It's it's just a modifier to the existing inactivity penalty on a correct target and correct source. Ben, quick comments. Ben. Yeah, this is just another comment related to like there was the discussion of changing emissions, which we've defied. but I do think if we are if we do do something like change emissions, then we should bring in these other things like the this penalty and MEV burn and all that sort of stuff. Okay. That sounds like a lot. It might be better to go piece by piece. but yeah, thank you. and yeah, Oshna, I think you were saying something that cut you off. I don't know if you had another comment. I was just gonna say that the this EIP was implemented by Chainsafe and Lighthouse previously before we slightly modified it. So it's not like crazy large by line count or anything. The the you know probably the biggest implementation criticism is yeah, it touches beacon state. So That is a fair point. People don't love doing that. Mm-hmm. Any CL team just want chime in? You've been awfully quiet on this one. Is there anyone like actively o opposed to it or is it all just indifferent slash lower on the list? Like I I don't know if there's anyone that's strongly for opposition these days. Yeah, we do tend to like it. I don't think we necessarily want to see it DFI, but we're also kind of concerned about the amount of inclusion included EIPs in the fork. so it's something we'd love to see stick around. but maybe not be obviously SF, you know, quickly. but we could we we could try to see it You know, towards the end if there's some more time. Yeah, that's mostly my aspiration here. Okay. there was a comment here from Monrico. Yeah, just echoing Ben's concerns that this might kinda open a can of worms of touching other stuff with it. So if there's no one that's like actively feeling strong about DFI, can we leave it, Chogalon? No, I feel like we need consensus to CFI, right? I feel like the bar should be high. my bit concern is that no one would even notice the CAP until a big outage comes, which but maybe that's enough. I you'd be surprised. I think even if it's like on paper more punitive, people will care a bit more. I think people haven't bothered to optimize too much because it's like, no, I can recover in four hours and I lost fifty cents of validator versus okay, I lost fifty bucks of validator. It's like okay, I'll be a bit better. we we we see like a liveness issue kind of once or twice a year, whereas we never see a correlated slashing issue in the last five, which I think is a missed opportunity. Consolidation, Barnaby, it's sorry, Alex, I just might answer Barnaby, but it's it's by each price. So it doesn't care if you're if you're consolidated or unconsolidated, it it's indifferent. Sorry, eat eat steak partners. so like a you know, it it it just multiplies by how much eat they have, not validate account. Yeah, just the amount of eat. but yeah, that'll be inside. I do feel like the bar should be we need strong support to CFI, not there's not yeah, basically indifference I think should not be CFI. and I'm not hearing enough strong support, I think, to CFI this today. So then I would say again, going off client team rankings and general opinions here, this is a DFI for today. Any CL teams wanna chime in? Favor of CFI in this. Okay. then we'll DFI. Thank you, everyone. let's see. I guess we'll just keep going here. Although yeah, we are getting towards time, so let's just be mindful of that. next here on the list, 8205, withdrawal credentials pre-registration. yeah, again, kind of mixed support here from the client teams. I believe this is okay. Yeah, George or Greg are one of you on the call here today. That will be me. Even though I'm not mentioned as a champion. Though I will occupy the rest of the call because I was not expecting that you will reverse the order. So if you allow me, I will occupy the remaining seven minutes. Is it okay? I will not it will not fit into. Let's let's see how it goes. Okay, fair enough. Give me a second to find the right presentation for it. Here it goes. here, I think I need to stop sharing then. Yes, please, if it's possible. Perfect. Okay. Okay. Okay. Let's go. I was not preparing for seven minutes, but I'll try to do my best. So withdrawal credentials pre-registration, H2O5. What's the problem we're solving here? The problem is simple, known for anyone, for anyone involved in Ethereum, has been with us since the inception of Beacon Chain. Within delegated staking, if you have a node operator and a delegator, node operator can basically rug the delegator by front running the deposit made by delegator with the data provided by node operator by simply putting One ETH deposit in front of the delegator deposit, but with its own withdrawal credentials. it's it has been 32 ETH back in the day. Now it can be even more if we are talking about OXO2 validators. But let's assume for clarity that it's 32 ETH. Okay, the problem is clear. what's the scale of the problem? And here, for those of you specific lovers of saying that Ethereum is staged by The same person, like you own Ethereum and your own validator key. Well, I have bad news for you guys. the majority of Ethereum is staked via delegated systems. And these are the numbers that are from the confirmed protocols that are using some sorts of declared protection measures against this vulnerability. And I take my word, the real number is like 70 or maybe 80% of all Ethereum staked. It's just participants like Coinbase, Binance, Bitmine. They are not declaring the ways how they protect from this vulnerability. But this vulnerability exists and impacts all of them. So the majority of Ethereum state is impacted. And now let's look at the current solutions. Again, this well-known and declared solutions, other than just doing something off-chain or standing with a solder iron next to your DevOps. So there are two main solutions here. One is bond or pre deposit, the other one is off chain guardian. Since we are running out of time, I guess you both know that pre deposit is just make one if pre deposit, wait for the validator to appear, if all good, make the remaining deposit with guardians. You check the deposit route. If all the deposits as of the deposit route are good and there are no front runs, you can make your own deposit, checking on chain that the current deposit route actually matches the one that you already checked. Both of these solutions come with the price. The first one with pre-deposit comes with the price of the double the entry queue for the majority of your stake. So basically, by doing that, you first of all need to find this pre-deposit. You should either sacrifice your one ETH from your protocol or from your from you as a provider, or you should take it from your node operator, like in cases of LIDA ST Vaults, Rocket Pool, or many other protocols. In case of off-chain guardians, I don't need to explain that. It's very simple. If you have like staking infrastructure, which is the core infrastructure of Ethereum relying on off-chain trust, this is definitely not the best solution in the world. And the problem is that even though there are two main types of the solutions, like all of the protocols that you can see on the screen and many more, they have their own bespoke implementations, like most of them. Which means that the same problem is solved like multiple, multiple, multiple, multiple times on application layer. And yes, you might say that, well, this is this is a problem of application layer. But at the end of the day, what Ethereum is without its application layer? So what's the solution? The solution is very simple. Like the validate there should be a way to agree beforehand that the validator, this, this, this validator withdrawals should go to this address. And how it's achieved within this EAP, pretty simple, in three steps. First of all, you sign the commitment where you say that this public key should have this withdrawal credentials. No race with with money at stake, like it is now, when you need to actually make a deposit and then hope that everything goes well or and you might lose this money. No, you are not putting any money at stake here. You just sign the commitment, you submit using a system contract on execution layer, same way as 70027251. Or any other EAP that is using system contract right now, and we have plenty of them. And then when you make a deposit, you can prove via 4788 that the pre-registration exists and you have a guarantee that whenever you make a deposit, your validator would appear with correct withdrawal credentials. Perfect. What's from the implementation side? And even though you might think, this problem has been with us for so long, so the solution must be super complicated, it is not. On execution layer, we just need a pre-registration request contract. Again, very similar to what we already have for 70027251 and others. And the code is ready for sure. And the LIDAR is happy to pay for the audit if it's necessary. On the consensus layer, like four basic operations, add pre-registrations to the beacon state, add request processing, remove expired pre-registration so that the state would not bloat, and add extra check on deposit processing as and that is it. That's simple. So who supports this EAP so far? We've been in talks with many protocols, many application layer participants, mainly security researchers. And these are just the examples of those who voice their support the loudest. And I I'm not quite sure like what should be the correct argument for the EIP to make it through. But if you have like the major staking protocols here on the screen supporting the EAP, if you have L2Bit. Saying that this is what is actually necessary, then I have no idea what's the better argument here. There is also the support from solo stakers on HubEva.net. And now the final question: why Higota? Why not later? Because this is a good argument to always say, let's put it to the other hard fork. Well, iStar Hard Fork will be fully packed with post-quantum migration, and I take my word. You guys will never accept this EAP for iStar Hard Fork because you all will be incredibly busy, as well as we will be with supporting the spot quantum stuff on the application layer site. So let's include it in Kagota scan the care code on the screen or go to EAP8205.com if you want to learn more about that. And that was it. And I made it right in seven minutes. Thank you all. Yeah, thanks for the slides. yeah, okay, we are at time, but I feel like we should just try to well, let's see. I think if there's you know much more discussion here, then it's probably best just to wrap up. But yeah, let's take a few minutes and try to see where we can get. yeah. So I don't know, there were some comments here, Barnabas Lion. Let me go here. Maybe that's unrelated. but yeah. Or any other client teams. Again, I can pull up the forecast page. And let's see here. Yeah. Okay. Tekku was in favor, then otherwise, yeah, pretty mixed support. Just to make it easier for client teams to to make a decision here. Again, the change itself, super simple. Like we we understand the way how hard forks work, and we understand that you guys don't want to put extra work in here. The thing is that all of the specs, tests, all of the stuff, like everything that could have been done other than the actual client development is already done. The problem is real and the solution is indeed simple. So deifying it right now would basically mean ignoring the problem that has been with us for five years when the solution is actually here, almost on the plate, very simple. And within future, like if you guys are thinking about post quantum and the post quantum deposit contract, yes, for sure it might have a fix for it. But if we will reject this EAP now. Then the likelihood of it being fixed in post-quantum deposit contract is very low because there are a lot of other problems to be solved there. And by having that, we are explicitly mentioning that we are reasonable people and we do not want to have issues, such long-standing issues as this one, within our base layer. So I hope there's enough arguments to make a clear decision here. Yeah, one quick question. Have you talked to EL teams about is there is a system contract, right? The system contract, yes, we talked to EL teams, we talked to the guys like the system contract is almost apples to apples to what we already have. So there is no rocket science here. And again, the only concern that has been voiced is that this contract should be audited. We are ready to pay for the audit. Okay. yeah, meditation doc and then Tomer, if you have brief comments. Yeah, we we are from ACK3, we support this because it's strength dedicated staking deposit. one concern is that like all protocol, all dedicated staking protocol need to see the need to adapt this protocol adapt this EIP, but th that's the only concern. Okay. Tomar. Yes. I'll make it shortly and now we're tight on time. I just want to say that from a security perspective, in my opinion, it's very, as Dimas said it's very simple. simplify, I mean, it simplifies a lot of security of Lido and other liquid stacking protocols in this in this context. for what been said in the chat about zero X2 solve this problem or just migrate to zero X2. I just to say even if you might get to zero X2, great. So now you have less validators. But you still want to withdraw ETH from your validators. For example, in Lido, if you want to exit, you need to withdraw the ETH from the validator. It exits, now you want to add new money, new ETH to Lido's validators, you run out of place, you need to deploy new validators. So this doesn't solve the problem. It maybe narrows the use case of entering new validators, narrows the user usage, but it doesn't solve it. So from security perspective, I think it simplifies a lot, a lot of the assumptions, the workarounds need to be done in a lot of liquid segment protocols to deal with this. honestly, first time I learned about this behavior, I thought this is like insane. Like the fact that you can do this race of who deposit first. and and I I was truly I was confident that this will be resolved already. So I'm happy this is proposed to be resolved now, but really it simplifies a lot of things and LIDO I think offers the solution they offer is very, very simple. And I think we should do it before the post quantum changes. Thank you. No, thank you. okay. It looks like Enrico is dropping, although I think he was one of the client teams and s at least one of the yeah, core devs in support of this. 'cause we did a get a strong ranking from Teku. but yeah, I guess it'd be good to hear from other client teams who haven't chimed in yet. I don't understand why the importance of doing this when there's already existing app layer solutions and it's gonna take a lot of effort from a lot of teams to get it implemented when it's already solved, like the problem is already resolved at the app layer. It is yeah, well well it is it is solved. but the every time something is changing on the consensus layer, the solutions have to be maintained. Like imagine that you have solved the problem. Same with the protocol layer. Like that's that I mean, we've we've already talked about, you know, granted in different contexts where different EIPs have to play in with new EIPs. And every single time you implement something at the protocol layer, it forces a rethought of that same EIP as other things are integrated with the same touching the same parts of state or the same part of the protocol. And I I don't see this as being different than that. and to be honest, that and really my my only concern, it's not even so much the complexity of the implementation. Because it's not, we did look at it. It's not it's not huge burden. It's probably like like Justin Troglia said, it's probably a medium effort. But there are going to be downstream effects and it only affects a portion of a network and it feels partially from a precedent perspective of when there's so much stuff that needs to be included in the core protocol, to be programming around specific use cases or specific stakeholders, which I not to discredit how important you guys are, because like that I I do want to say that out loud is like we do appreciate the importance of you guys on the network and and and the good work you guys do. the problem comes in though is that there's a lot of to use a bad or or to to say a cheesy phrase, but there's a lot of mouths to feed when it comes to different use cases. And really the core protocol it feels it feels like we need to focus on the core protocol. and then as time comes up, we can start to think about some of these other. you know more limited use cases, which have a much smaller stake stakeholder pool that they benefit. And that really is the part that I think is the most important part of the governance protocol or or the process is making sure that we're targeting and focusing protocol development at the at the you know at the at the core protocol level towards things that'll benefit all users and and the core protocol itself. You're absolutely right, and I'm fully with you. And I'm very happy that whenever I open my mouth, you guys think that anything that people from LiDO can propose benefits LIDA. But I explicitly mentioned in the presentation that ask any any staking protocol that exists on the network, like EtherFi, Rocketpool, whoever else, all of them Are using delegated staking. And this is the core. If it was only for Lido, I would not have been here and would never propose something that benefits only LIDO. The thing is that consensus layer is about staking, and the majority of all Ethereum staked is staked in a delegated way. And this problem affects each and every person, protocol, product, whatever that does delegated staking. So I think that your assumption about the level of impact and about how wide the variety of clients and how much of actual Ethereum staked is involved is definitely off because the right assumption here and the right estimate here is that the absolute majority of Ethereum is staked in a delegated way. So I really want to stress that this EAP does not solve particular LIDA issue. It solves the issue that each and every staking protocol has to solve on their side. And there are tons of them. Like if you just take the most well known one, you will already have five or more. And I'm not speaking about, again, those who are not declaring how they deal with this issue, but they all have to deal with it, unfortunately. True. And I fully understand that for anything that is just for LiDO should not be in the core protocol. But this is not just for LIDO. And it's not so much that I I I say just for Lido. It's more of like there there's a lot more there there's many more stakeholders than just people who are staking. And while that is a very important function in order to get the the chain doing what it needs to do, there's a lot of other things at the application layer that are not related to staking. and that's really I think where I think a lot of the sentiment, at least for some of the people that we've we've spoken with, because we did talk to a couple of other teams about this, and also within our own team. And, you know, that and it's not that we don't take the situation seriously, but there is going to be, as a number of other people like Botus and Kingy had mentioned, there's gonna be a lot of work done when PQ comes in it literally in the next fork we're gonna start looking at BQ keys. So it's you know, it just feels like it might be better to solve it solve it there once instead of solve it now and then have to reinvent the wheel again. We should wrap up. but thank you everyone for the discussion. And yeah, I mean, I'll just play back what I'm hearing here from the different client teams that yeah, I mean they think this is an important problem, but also it makes the most sense just to handle with PQ at this point. so yeah, you know, I recognize there's a maintenance burden here for, you know, apps who touch this and that's not ideal. But I also am not hearing support here to go ahead and see if I this today. So I would propose we DFI. And yeah, it does seem like a nice path forward here then is to take the work from here, jump into the PQ design, and then settle this problem then. Yeah, Greg, final comment. Yeah, so because now I think we're running out of time and also yeah, there are still some open points. Could we just yeah, leave it like the final decision for next call? Because I don't think there is enough information now to just say that like at least this discussion that happened now doesn't sound like DFI to me. So because yeah we're we were running out of time. It was just seven minutes, we took some more time, but I think Yeah, it deserves a bit more discussion. Like most of VIPs discussed much more than this. So we can start next call from this one, right? Yeah, okay. Let's defer this than today. we'll start next call with the gridoscopy and we'll just come back to this. But again, yeah, in terms of time boxing, just so everyone's clear, yeah, there'll be a you know, five minutes I think at most to get back into this. yeah, let's do it that way. And then we'll make a call, hopefully pretty quickly on the next call. And yeah, then we will do that. Okay. Thanks everyone for staying over. but yeah, let's go ahead and wrap up because we are quite over time today. So thank you.