All Core Devs - Consensus #189

Transcript

Alex Stokes: Okay, I think the way it's set up is, we're already streaming, so… That being said, let's give people… another minute or 2 to join, and then we'll get started.

Okay, we're a little over 50 people here, and yeah, seems like a good place to get started. So, 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 fun call. We'll touch on Glamsterdam. We just have the Sepolia fork and Hoodi coming up. A few other things there. and then we'll continue with Hegota again. A couple of 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 Sepolia fork, seems like it generally went pretty well. Anything anyone would like to add or point out about the fork?

Yeah. Time for Hoodi, says Barnabas 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 Sepolia, and it lined us up for, yeah, the the next networks coming up. Which brings us to Hoodi. So Hoodi has been scheduled for October 26th, 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 ethrex. I'm trying to keep an eye out. But yeah, one thing we'll do is put out a blog post from the EF.

Like we did for Sepolia, we'll do this for Hoodi. 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 12. 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 because, again, Hoodi's a pretty distributed testnet. So We will need, yeah, people will need time to update. Okay. Otherwise, then, yeah, Hoodi is on rails moving forward. Anything else on Hoodi that we should touch on?

Barnabas Busa: 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, end up And hopefully propose a… First or the second slot, probably.

Alex Stokes: 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 Glamsterdam. And, like I said, that is a nice segue into the next, topic here. So… I believe this is Dmitrii. He brought up this issue from the consensus-specs that he wanted to discuss. Yeah, this seems relevant to… builder deposits here. is…

Dima Gusakov: 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&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 all of the other deposits are considered so-called top-ups. And for some reason, well, maybe it 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 similar way, I mean that if you have a single deposit in the deposit queue at the time of Glamsterdam Hard Fork. with withdrawal credentials with the prefix of 0xB0, which probably stands for builder, then any other deposits that are also in the deposit queue at the time of the hard fork 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 credentials. 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, 1 ETH pre-deposit, your validator appears on the 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 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 further deposits with a validator prefix within the withdrawal credentials, instead of crediting those deposits to the builder, credit them to the validator. Because as far as I remember, after Glamsterdam 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 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… the fix to the spec is also linked to the issue. It's a very small and pretty simple fix that would make life way easier for the majority of the application layer protocols who rely on this. pre-deposit mechanism for… to secure their deposits, and it wouldn't also be a major lift for core teams to make this small change. So, that is pretty much it.

Alex Stokes: 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 are we 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 wanna chime in.

Anyone else from the client team? Can I ask?

Dima Gusakov: Like, 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 want to 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, oh, hey, go and do, like. 10 or more, I don't know, 20, 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 Devs.

Alex Stokes: Barnabas.

Barnabas Busa: I'm a 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 Sepolia. We are about to schedule Hoodi, well, we have scheduled Hoodi 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 going to happen.

Dima Gusakov: But we still have time, I guess, to have it on Hoodi again. The fix itself is very simple, and it doesn't matter that much. how, Sepolia was delivered, because again, this is a one-time function, this is not a change to consensus, and I… I'm not even sure that this particular case was actually tested during the real Sepolia 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.

Alex Stokes: 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'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 Sepolia again somehow. then Hoodi, 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.

Pavel | MixBytes: Also, let me add from the security perspective of this issue, because we audited multiple approaches to solving this issue, like a pre-deposit guarantee contract. We reviewed multiple approaches from different protocols. Who wants to… solves 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 root. And, you have to… Just, adapt to… Like, any changes in ConsensusLayer, so… It looks like, Workaround, which can be easier solved.

In my opinion.

Alex Stokes: 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 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?

Matthew Keil: 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 Hoodi, 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.

Alex Stokes: Okay. Barnabas.

Barnabas Busa: Just a quick question, whether this would be still a problem post-fork, or this is just… No, this is…

Dima Gusakov: Yeah, 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.

Barnabas Busa: But then, can't you just… Make no deposits in that block.

Dima Gusakov: 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… 22 days, and I hope that… 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.

Tomer Ganor: Someone that audited the relevant code that Dima is referring to, it's very not trivial to… to deal with this from the on-chain perspective, besides us actually pausing this relevant part in the code for, as Dima said, weeks, or, like, even to upgrade the code is not trivial at all. Together with this. It's a completely new scheme of, like, how does the flow of the system works. in the relevant code in Lido.

Alex Stokes: I'm just reading the chat here. Yeah. Yeah, I mean, this does seem to be the read that core developers wanted to stick to the schedule right now. It would involve… Yeah, like, there's more risk if we were to… Change Hoodi. And Mainnet, and not have, you know, another Sean Gold Sepolia. 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 timebox 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's possible, but… I'm not sure. It sounds like you've done all the legwork already. So, yeah, again, unless anybody wants to explore this further, let's go 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 Hegota. So, yeah, the main thing today is just to continue the scoping process. First up, though, we…

Barnabas always 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?

Barnabas Busa: Yeah, sure. So, EIP-8365 is basically, disabling new 0x00 validators, and. as the EIP describes it right now, those, that would still make a deposit after the… After the fork, they would get all that ETH burned, basically, and, I kind of disagree with that. Like, I agree that we need to stop 0x00 validators, but mistakes can still be made, so I think it would be better if. We would still allow those validators to join just Basically, have no validatory 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 re-queued, 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. So then all of them would change to a 0x01, and we would get a huge inflow of ETH. Come to the chain.

Alex Stokes: Okay, thanks. Has anyone else had time to look into this? In terms of…

Barnabas Busa: This is very recent, so I wouldn't expect anyone to have taken a closer look.

Alex Stokes: Okay. Yeah, then I guess the ask today is just to say… you'd like to update the EIP with this, and… Yeah, I suppose from here, people can take another week, just to look at the changes.

NC: 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 Hegota. Why would we have sympathy? to those 0x00, 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.

Barnabas Busa: So you could make a deposit with 0x00 in Aquatar, for example, or in Gloas. And, you would have a pending queue of, let's say, 60 days. And Within 40 days, we would have a hard fork. And in 20 days after the fork, you would have 32 burned ETH. So you could…

NC: Okay.

Barnabas Busa: 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 ETH burnt. Okay.

NC: Yes, I do agree with this point. I think I, I asked this open question on Ethereum Magicians. a while ago, but nobody answered, but I think essentially what we want here is to grandfather those 0x00 deposits that were submitted before the Hegota fork. And I thought about this, and I think the easiest solution here is instead of guarding the apply pending deposits, we just 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 would solve, the case that you're describing. But if the deposit is submitted. After Hegota is activated, then I have no sympathy, for, for this case.

Alex Stokes: 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. Okay. Then, from there, next topic is to continue scoping of the PFI EIPs. Let me share Forkcast 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?

Barnabas Busa: Yep.

Alex Stokes: Okay, thanks. Okay, cool. Let's see here. So… this is filtered for… CL EIPs, 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, EIP-8025 optional execution proofs at the very end of the last call, but I 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.

Ignacio Hagiopan: Yes.

Alex Stokes: Okay, I think I need to stop sharing, and then you can share.

Ignacio Hagiopan: Cool, I will share my screen. Can you see my screen?

Alex Stokes: Yep, I can.

Ignacio Hagiopan: 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 EIP-8025 is trying to do is basically allowing opt-in proofs for execution proofs into the network. And opting nodes to verify them, to collect metrics, and start having more understanding of how this, would work… would work in the network. An important point that we keep stressing is that every validator keeps re-executing the payload, and Attesting as… exactly as they do today. The EIP 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 node operators. They won't be pulling these proofs or something like that. Only node operators that are interested in, helping collecting metrics and understand Networking implications can really obtain on Judy's. 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 EIP-8025 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 front.

And… On the right-hand side of this first slide, we have some summary of readiness. on ELs, CLs and guest programs. On the EL side, we have already 6 of them, integrated into our Hive dashboard. EL clients, our main responsibility within the EIP is basically, implementing execution witness generation, which is basically the information the prover needs for proving. And 6 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 iHub upstream the changes into the main branch. We have Prysm already with an open PR based on Glamsterdam.

We have draft PRC in the ORCLs. And on the guest program side and zkVMs, we have multiple combinations of integrations. This is not, like, blocking for EIP-8025, but there's really good progress on that front. If you want to know more details about this, you can look at the Hive dashboard 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 we want to CFI 8025 in Hegota 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 EthPandaOps 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 and EIP, but the strongest argument here is mainly on the development and efficiency of the protocol. The EIP-8025 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 de-aggregates this number, because my sum a bit scary. Only 65 lines are really touching the STF code, which is maybe the most sensitive part of the spec.

most of the… PR are mainly testing, framework changes or tests for EIP-8025, which we have a lot. CI changes, 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, we are 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, like. At least for… for… for a… for… for a year, and it has been rebased on top of at least, five devnets 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 CL core Devs.

And these 56 line changes, I think it's really important to stress, because the main point here is that we don't want this EIP to really clash with other EIPs that may get scheduled for Hegota, so it shouldn't really interfere with other efforts in the fork. And the other main thing that we want to stress is Proving Blocks might have some. We might want to do more, experimentation on how ProvingBlocks. interact with our upcoming changes, such as PBT. And PBT already has its own branch in execution specs. We already have our own branch of 8025. They might be based on different base branches, and if we want to understand the implications 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 ProvingBlocks in L1 will be something That will happen in the future. It would simplify a lot, to really upstream, our work that, We feel it's pretty mature and the EELS 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, of the changes. And this will also simplify some pipelining of releases, such as releasing. stateless log execution within the main releases from EELS, and we won't have, like, this Umm. Lagging between, like, 80-25…

let's say zkVM 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 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 attestation. Because this is not safe. If you put this EIP in an informational one, or somehow in an ERC, as someone suggested, I don't think this is, like, a strong rule that we are putting in the protocol.

Umm. So, 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 CLs 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 attest 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 the 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 implementations to follow the rules, because this is, like, our main assumption. And as a last point, some random questions, if we need repricing for EIP-8025, that is not the case, because, proofs are not really required for attestation, as we clarified before, so repricing is more on the mandatory proofs. Side of the story, so into the future. And regarding picking zkVMs or these programs, again. This is not something for EIP-8025, 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, standardizing things so people have a coordination point, to really do the work and move forward. So that's everything I wanted to share, and I'm happy to receive any questions.

Alex Stokes: Okay, thank you. Yeah, just, process point, let's try to timebox 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, I was summarizing the chat here, like, the question's just, like. you know, do we need to CFI this versus is there some other way to… get the, you know, R&D work that you were just calling out without that? Any client teams want to… oh, yeah, go ahead.

Ignacio Hagiopan: Yeah, I just want to say that the main interest from our side is to upstream this into the specs. The EELS 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 process rules and honor the way they work. That's kind of our take. on why we need to CFI this big instead of simply keep working in parallel.

Alex Stokes: Yeah, I see. Lukasz?

Łukasz Rozmej: 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… this is being tried to CFI 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 web, that's hard to untangle and discover everything, so… we can consider trying to tackle this instead of CFIing also, but… CFI is simpler with the current process.

Alex Stokes: Yeah. I don't know enough about how ELs are set up, on this point, but I do wonder if, you know, rather than a branch of this, because I assume there's a, you know, branch that has this code already. In the EL 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 Forkcast screen, but yeah, if any ECL teams want to chime in while I'm doing that. Okay, I lost the chat now.

Are there any ECL teams that want to chime in on this? I pulled up the Forkcast here because, yeah, going by client rankings, it's pretty mixed. Okay, at least kingy here from Lighthouse, you know, they obviously support the work. But not so sure on CFI.

Saulius Grigaitis: I think that, well, I mean, it's something that, people want, I think, in some sense, but my main concern is actually the scope. 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 the moment, the scope of FOCIL and… essentially, the scope of FOCIL is the main finger. That is blocking me to to CFI this.

Alex Stokes: Anybody else? Yeah, I mean, personally, I'm here at Lukasz, 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.

Lightclient (Matt Garnett): Yeah, I mean, I've kind of said in the 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. It's a feature of ethereum. And have had to work in parallel or on their own branches for many years. I don't think that we should. I'll be changing this just to support. To optionalists, or an optional feature.

Alex Stokes: Yeah, Iván, your hand's up.

Iván | ethrex: Thanks. Yeah, on the EPIC side, we support moving EIP-8025 to CFI for Hegota. The zkEVM 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 EIP 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 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 this EIP already has in the code that Ignacio already shared. I will share the dashboard Again, the Hive 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 EIP-8025, 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.

Lightclient (Matt Garnett): I'll 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. Like, 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. Who's that?

Ignacio Hagiopan: Yeah, I would say that we should focus more on the process here, and 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 the execution specs, has been maintained for a pretty long time. A lot of people are really working on this. You have the safety guardrails to not really put the network at risk. The main thing we want to do is to upstream work that is already quite mature. And it's 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… will be really sad and inefficient when wasting scarce resources we have, trying to maintain all this stuff when it's really truly upstream.

Lightclient (Matt Garnett): That is just not a good reason to make a EIP. A core EIP passed. Governance. Because the branches are difficult to manage.

Ignacio Hagiopan: Right, but who is managing that? It's basically me and the EELS team, right?

Lightclient (Matt Garnett): doesn't mean it's… 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 end. Did we have a bit different process? Like, maybe. But I don't think that this is… Good reason to do this.

Ignacio Hagiopan: I disagree on that, in the sense that that might be.

Lightclient (Matt Garnett): I mean, of course you disagree. You're the one who has to rebase it.

Ignacio Hagiopan: But it's not about me, it's about, like, resources that we have to do all the changes that we want for Ethereum, right?

Lightclient (Matt Garnett): It's never been easier to rebase features. Like, 2 years ago, maybe it was a different argument, but, like, now, just ask Claude to rebase the feature. 10 minutes later, it's rebased.

Alex Stokes: so…

Ignacio Hagiopan: It's not about rebasing, it's about, like, complexity of how EIPs interact with each other, too, so it's…

Lightclient (Matt Garnett): Okay, now that's different. That's a very different argument.

Ignacio Hagiopan: But now we have to.

Lightclient (Matt Garnett): We constrain ourselves. We have to potentially constrain ourselves based on an optional EIP. That's a totally different argument than you were making and I think that that's like way overstepping. But they shouldn't. What we should be accepting right now.

Alex Stokes: 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 ECL team chime in if they want to go ahead and CFI this. Now is your chance to speak up. See all teams. If you feel differently,

Emmanuel Nalepa: Yeah, Manu from Prysm. So actually, in our ranking, we… said, we… We did not write a big priority for this, because this EIP, yes, does not require a hard fork. Yes, that was the main reason. However, NITAS and Prysm are actively working on this EIP. Yes, Lighthouse has merbly CIP in unstable and Prysm has a branch. And so… CFIing or not, this EIP would not make a big difference about the… the effort we deploy to work on this EIP. Because that's… it's optional. So in my opinion, we could CFI it. And so it will kind of show that. So, yes, at least a few clients team are keen on working on this EIP.

Alex Stokes: Enrico.

Enrico Del Fante: Oh, and just a comment on the optionality, because it looks… it's weird to me. So, okay, then the optionality is… Around consuming the proofs. But since there is a gossip subnet now that is required by this, it means that all the nodes should support in helping disseminating the proofs, and then decide optionally to use the proof or not. But if this goes in, anyway, I believe all the clients must support the new… the new cells, the new topic, and support the dissemination of the proof. So, I mean… The optionality is not complete.

Emmanuel Nalepa: I mean, I don't know if it's time to enter too much technical details here, but no, it's not true. I mean, if a node, should opt in, with this EIP, it just exposes an EPROOF field in its node record, ENR, and that's it. And, you know, other PR wanted to… to use as proof, just have to to to look for peers in the network with this, with this e proofs field, and then The peer will know that other peers will subscribe to the.

Enrico Del Fante: Oh, okay.

Emmanuel Nalepa: Execution proofs. So yeah.

Enrico Del Fante: Okay, so it's optional also into participating in the networking layer.

Emmanuel Nalepa: Yes, exactly, exactly, yeah.

Enrico Del Fante: Oh, okay.

Alex Stokes: Okay. So maybe now a bit stronger support for Prysm, 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.

Emmanuel Nalepa: I mean, I don't know if there is some Lighthouse people here, but Lighthouse already merged into the unstable branch EIP-8025, so it's… For me, it's an implicit support to it. And why would we want to merge in, in your unstable branch if you don't support the EIP. It does not make sense. Yes, said otherwise, who is against it? Yes, as Ignacio asked in the chat.

Alex Stokes: Potuz, I'm assuming Enrico your hand was from earlier.

Potuz: Oh, Enrico was up for earlier. I am against this, if this means merging into Heze. I'm sure that Manu's Manu's branch can be merged and will be merged into Prysm's 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 maintainer is forced to rebase into what 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 next fork.

I think this… this should not be happening for optional features.

Alex Stokes: Francesco.

Francesco Risitano: Yeah, I just wanted to touch on the interplay of this EIP in regards to the specs. So the execution proof handler is very isolated. And, you know, we do introduce a 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 review that and come to a conclusion themselves, but that's my personal opinion, at least. It's quite isolated, and that was done, you know, 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 Devs.

Alex Stokes: Yeah, thanks for the comments. Yeah, that's all helpful, but yeah, it just seems like there's not consensus here amongst the CL teams to merge this in, for this work. So, I… my read is that people will 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.

Mario Vega: Yeah, sorry, yeah, basically just want to echo the exact same problem that Potuz is having with merging into main 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, zk EVM 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 merging into the main development branch. I don't want this to be, like, enshrined if the EL Devs or the CL Devs are not in favor of it. So, yeah, that's my concern, right? Basically. Thank you.

Alex Stokes: Yeah, thanks. Again, yeah, I'm not as familiar with the EL specs. On the CL 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, you know, the actual engineering easier, but again, in terms of today, I think we go with DFI for this, and move forward. So… Let's do that. Okay, let's see here, we have about a little under 30 minutes. So… And 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's rankings. that, I think, will help us just move through some EIPs, and then, yeah, we're ultimately gonna have, yeah, more EIPs 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 RowDAS here. Let's see. Yeah, Csaba, here is the champion. I don't know if you'd like to say anything briefly on this.

Csaba Kiraly: Yep.

Alex Stokes: Are you on the call? Okay, yeah, go for it.

Csaba Kiraly: Yeah, so… I just have smells.

Alex Stokes: There's definitely an echo.

Csaba Kiraly: some technical problems. Oh, should be good. Yeah, so… RowDAS has… The goal of fixing, past design decision that we made when we introduced PeerDAS. It's planning to fix two things. One is the excess… CPU load that we have on. On large nodes, and the other one is, the reliance on these nodes. 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 any way blobs today, so we should not invest 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 excess CPU usage, so the mechanism is based on a duty allocation, basically.

And, we could… do that, and that's very simple. So that is this B variant, if people feel that the other one is too complex. Although that's what I'm more passionate about, which we just don't rely as a protocol on those entities. Anyway, there is this B variant, 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 that, and this would just allow us to distribute the load in the network in a simple way, and just distribute 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 Hegota. I have published some design notes next to it, so feel free 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… Who is up to it?

Alex Stokes: Okay, thanks. Yeah, any client teams want to speak to this?

Csaba Kiraly: My, yeah. Oh. Maybe there was T. My speaker is muted, so I didn't… I didn't hear the responses, if there were responses.

Alex Stokes: I don't think there's been any yet, yeah. But yeah, just going off of this, Yeah, didn't hear from Lodestar Prysm, according to Forkcast here. Nimbus was in favor, but otherwise, yeah, Teku, Lighthouse, Grandine. Were against. Any clients want to chime in with any more color right now?

Csaba Kiraly: The main argument I've seen is that we don't have blobs.

Alex Stokes: Yeah.

Csaba Kiraly: I'm not sure that we'll find it in the following many months, but, I don't know that.

Alex Stokes: 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 of blobs are at today. This isn't… Doesn't feel like the most urgent EIP. Okay. Any other CL teams want to chime in here? Otherwise, we'll just go with DFI. Okay. Thanks, Trevor. Next up, we have EIP-8359. This is BeaconBlock reporting field. And the champion was hanniabu. Are they here, or is one of the authors here that would like to Say something brief about this.

Luca | Vero: hanniabu isn't here, as far as I know, but I can… Say a few words. So, this is the new proposed BeaconBlock field, aimed to give us more data about client diversity on the network. The… that's the… 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 BeaconBlock, 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… 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.

Alex Stokes: 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 Hegota 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's some… comments here in the chat. But Paul, I think, was also an author. So I hope they'd be in favor.

Okay, then let's DFI 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 going to see who…

Oisín Kyne: and.

Alex Stokes: But yeah, go ahead.

Oisín Kyne: Yeah, I'm champing and would share a screen if we had 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, but we've never seen a correlated slashing penalty live on mainnet. this EIP is… Relatively mild in terms of what it, does, it increases 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 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 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 5 years of proof of stake. We've, I think, 3 different clients that, if they fail. will cause a liveness issue, and if they fail together, like in Hoodi or in Holesky, 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 the, 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 5-10% of the network in OVH and Hetzner in certain data centers, so this would discourage that whenever they have liveness issues, which is occasional.

Alex Stokes: Yeah, thanks. You mentioned slides. If you could keep it to, like, 2 minutes, I think I just have to.

Oisín Kyne: Yeah.

Alex Stokes: Okay, but yeah, let's just be mindful of the time.

Oisín Kyne: That will do. Can people see this?

Alex Stokes: I can, yeah.

Oisín Kyne: Sweet. Okay. I won't show too long. This is the one you can mess with what client 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 EIP 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 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, 4 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, 20 hours to 4 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.

Alex Stokes: Alright, 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 can put the Forkcast page back up. But ultimately, it was not rated super well. So I think that would lean DFI for Hegota. Any client teams want to add any color?

Oisín Kyne: I would say got an S tier from ethrex. And naturally, all of the smaller clients have a bit of incentive to be more in favor of it because it, you know, hurts them less.

Alex Stokes: Yeah, that's helpful, although ethrex won't be implementing the EIP, so…

Oisín Kyne: No, fair.

Alex Stokes: more.

Oisín Kyne: As for the implementation, it is.

Alex Stokes: the.

Oisín Kyne: 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. moving average, so as to whether or not to scale the penalty. The EF protocol team kind of originally DFI'd it by saying it touched slashing, which it didn't. It's just a modifier to the existing inactivity penalty on a correct target and correct source.

Alex Stokes: Hmm. Ben, quick comments?

Oisín Kyne: you.

Ben Adams: Yeah, this is, just another comment, Related to, like, there was the discussion of changing emissions, which, we've DFI'd. 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.

Alex Stokes: Okay, that sounds like a lot. It might be better to go piece by piece. But yeah, thank you. And yeah, Oisin, I think you were saying something, I cut you off. I don't know if you had another comment.

Oisín Kyne: I was just gonna say that. the EIP-7716 was implemented by ChainSafe and Lighthouse previously, before we slightly modified it, so it's not like… crazy large by line count or anything. Probably the biggest implementation criticism is, yeah, it touches Beacon State, so that is a fair point. People don't love doing that.

Alex Stokes: Any EL teams want to chime in? You've been awfully quiet on this one.

Oisín Kyne: Is there anyone, like, actively… opposed to it, or is it all just indifferent slash lower on the list? Like, I don't know if there's anyone that's strongly for opposition these days.

Matthew Keil: Yeah, we do tend to like it. I don't think we necessarily want to see it DFI'd, 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, SFI'd, you know, quickly. But we could, we could try to see it. You know, towards the end, if there's some more time.

Oisín Kyne: Yeah, that's mostly my aspiration here.

Alex Stokes: You're there. There was a comment here from Enrico. yeah, just echoing Ben's concerns that this might kind of open a can of worms of touching other stuff with it.

Oisín Kyne: So if there's no one that's like actively feeling strong about DFI, can we leave it chug along?

Alex Stokes: Well, I feel like we need consensus to CFI, right? I feel like the bar should be high.

Łukasz Rozmej: My big concern is that no one would even notice the CAP until a big outage comes, which… but maybe that's enough.

Oisín Kyne: 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, oh no, I can recover in 4 hours, and I lost… 50 cents a validator versus, okay, I lost 50 bucks a validator. It's like, okay, I'll be a bit better. 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 Barnabe, it's, Oh, sorry, Alex, I just might…

Alex Stokes: American.

Oisín Kyne: Barnabé, but it's it's by ETH price. So it doesn't care if you're if you're consolidated or unconsolidated. It it's indifferent. Sorry, ETH stake, Barnabas. So, like, you know, it just multiplies by how much ETH you have, not validator count.

Alex Stokes: Yeah, just the amount of these. But yeah, that'll be inside. I do feel like the bar should be… we need strong support to CFI, not… you 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 the DFI for today. Any ECL teams want to chime in? In favor of CFI in this? 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?

Dima Gusakov: It 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 7 minutes. Is it okay?

Alex Stokes: I.

Dima Gusakov: It will not fit into.

Alex Stokes: Let's… let's see how it goes.

Dima Gusakov: Okay, fair enough. Give me a second to find the right presentation for it. There he goes…

Alex Stokes: Oh, you're right.

Dima Gusakov: thing.

Alex Stokes: I need to stop sharing then.

Dima Gusakov: Yes, please, if it's possible. Perfect. Okay… Okay, okay… Let's go. I was not preparing for 7 minutes, but I'll try to do my best. So, withdrawal credentials, pre-registration, EIP-8205. 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 0x02 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 staked 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 stake. 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 stake 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 ETH pre-deposit, wait for the validator to appear, if all good. make the remaining deposit with Guardians, you check the deposit root. If all the deposits as of the deposit root are good and there are no front runs, you can make your own deposit, checking on-chain that the current deposit root Actually matches the one that you already checked.

Both of the solutions comes 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 1 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, Lido ST Vaults, Rocketpool, 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 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 validator withdrawals should go to this address. And how it's achieved within this EIP? 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 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 it using a system contract on execution layer.

Same way as 7002 and 7251 or any other EIP 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 preregistration 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, oh, 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 7002 and 7251 and others. And the code is ready, for sure, and the Lido 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 simple.

So, who supports this EIP so far? We've been in talks with many protocols, many application layer participants, many security researchers, and these are just the examples of those who voice their support the loudest. And I'm not quite sure, like, what should be the correct argument for the EIP to make it through, but if you have, like, major staking protocols here on the screen supporting the EIP, if you have L2BEAT saying that this is what is actually necessary, then I have no idea what's the better argument here. There is also a support from Solo Stakers on HapEVA.net. And now the final question, why Hegota, why not later? Because this is a good argument to always say, oh, 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 EIP for ISTAR Hard Fork, because you all will be incredibly busy, as well as we will be, with supporting this post-quantum stuff on the application layer side.

So, let's include it in Hegota. Scan the QR code on the screen, or go to EIPA205.com if you want to learn more about that, and that was it. And I made it right in 7 minutes. Thank you all.

Alex Stokes: 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. Nico here. Maybe that's unrelated. But yeah. Or any other client teams. Again, I can pull up the Forkcast page… And let's see here. Yeah, okay, Teku was in favor, then otherwise, yeah, pretty mixed support.

Dima Gusakov: Just to make it easier for client teams to make a decision here, again, the change itself Super simple. like, 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 DFIing it right now would basically mean ignoring the problem that has been with us for 5 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, yeah, for sure, it might have a fix for it, but if we will reject this EIP 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 there. So, I hope, there is enough arguments to make a clear decision here.

Alex Stokes: Yeah, one quick question, have you talked to EL teams about… because there is a system contract, right?

Dima Gusakov: The system contract, yes, we talked to EL teams, and 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.

Alex Stokes: Yeah, meditationduck. And then Tomer, if you have brief comments.

meditationduck: Yeah, we, we are from ACK3, we support this because its strength dedicated staking deposit. One concern is that. Like, all protocol, all dedicated staking protocol need to. See the… Need to… adopt this protocol, adopt this EIP, but that's the only concern.

Alex Stokes: Great. Tomer?

Tomer Ganor: Yes, I'll make it shortly, I know we're tight on time. I just want to say that from security perspective, in my opinion, it's very, as Dima said, it's very simple, and… simplify, I mean, it simplifies a lot the security of Lido and other liquid staking protocols in this… in this context. For what, been said in the chat about 0x2 solve this problem, or just migrate to 0x2, I just want to say, even if you migrate to 0x2, great, so now you have less validators, but you still want to withdraw it 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 usage, but it doesn't solve it.

So, from security perspective, I think it simplifies a lot, a lot of the assumptions, the workarounds needs to be done, and a lot of liquid staking protocols to deal with this. Honestly, the first time I learned about this behavior, I thought this is, like, insane, like, the fact that you can do this, race of who deposits first. And I was surely… 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 And the solution they offer is very, very simple, and I think we should do it before the post-quantum changes. Thank you.

Alex Stokes: No, thank you. Okay. It looks like Enrico's dropping, although I think he was one of the client teams, at least one of the, yeah, core Devs in support of this. Because we did 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.

Matthew Keil: 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.

Dima Gusakov: It is… yeah, 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.

Matthew Keil: Same with the protocol layer, like, that's… that… I mean, 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 don't see this as being different than that. And to be honest, and really 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 a huge burden, it's probably, like Justin Traglia said, it's probably a medium effort, but there are gonna be downstream effects, and it only, affects a portion of the 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, I do want to say that out loud, is, like, we do appreciate the importance of you guys on the network and the good work you guys do. The problem comes in, though, is that there's a lot of… To use a bad, or 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 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 the process, is making sure that we're targeting and focusing protocol development at the, you know. at the core protocol level towards things that'll benefit all users and the core protocol itself.

Dima Gusakov: 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 Lido. But I explicitly mentioned in the presentation that ask 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 ConsensusLayer 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 EIP does not solve particular Lido 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 5 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 anything that is just for Lido should not be in the core protocol, but this is not just for Lido.

Matthew Keil: And it's not so much that I say just for Lido, it's more of. Like, there's a lot more… there's many more stakeholders than just people who are staking, and while that is a very important function in order to get 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 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 gonna be, as a number of other people like Potuz and kingy had mentioned, there's gonna be a lot of work done when PQ comes in.

Literally in the next fork, we're going to start looking at PQ 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.

Alex Stokes: 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, I think this is an important problem, but also… 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 CFI 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.

Greg K | Lido: 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, it doesn't sound like a DFI to me. So, because, yeah, we were running out of time, it was just 7 minutes, we took some more time, but I think, yeah, it deserves a bit more discussion. Like, most of the EIPs discussed much more than this, so we can start next call from this one, right?

Alex Stokes: Yeah, okay. Less defer this than today. We'll start next call with the greater scoping, we'll just come back to this. But again, yeah, in terms of time boxing, just so everyone's clear. Yeah, there will be a, you know, 5 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 and wrap up because we are quite over time today. So thank you. I'll go ahead and just say deferred. Yeah. Okay, thanks everyone. Goodbye.

Lightclient (Matt Garnett): Thanks, Alex.

Potuz: Bye-bye.

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