Consensus Layer Meeting 184 [2026-08-06] | ACDC 184

Akash Kshirsagar: so we have a packed agenda today. So let's start off. first item on the agenda is DevNet updates. Do we have Barnabas on the call for DevNet seven bugs? Yes, we currently have a fork of Prism running to submit some invalid blocks and Prism was basically unable to sync up to those. I I think currently Prism is on a parallel fork. we have let the team know, but I'm not I'm not sure what the latest is from their side. So right now I think everybody other than prism is up to head. Hey, awesome. And I think Dead Star as well. So Lodestar and Tony have been trying out some tests. as far as I know, there's a PTC fix spending on Lighthouse. Okay. If that's the case, then the next open point on the agenda was a beacon API PR, um630. We have it still open. is it possible to get it merged by the before DevNet 8? is there any objection from clients for this? Okay. if there's no objection, then yeah, I guess we should yeah, get it merged and then have it in the spec for DevNet 8. we'll have the DevNet 8 discussion sort of immediately after this. there's one more open topic for DevNet for what gets scheduled in DevNet 8. Bozul wanted to bring up Spa's blog pool and revisit the discussion. Bozul, do you have the floor? Hi. so at the last ICDT we discussed making the EIP eight zero seven zero engine APIs purchase updated V4 and Gap Loss V4, those mandatory. So most EL clients did not seem to object and there are already some implementations, but Lighthouse team raised the concern. on piggybacking the custody field on purchase update. So if you have some if if any CL client teams have any thoughts or concerns about this, I would appreciate it. do any CL devs want to speak up? Okay, I guess we can discuss this in the interop chat on ETH R and D. Is that fine for Bozo? Yeah. Yes, for for the question of whether any CL clients have implemented this. currently Prism and Whitehouse I guess have grab have a PR for this. And yes, I think it's good to discuss this on interop channel, but I'm not hearing any counter proposal or strong objection. So I think it would be good to just decide if there's No objection then until certain date, then let's just do it as is. So something like that. Yeah, agreed. agreed. I think if there's no counter objection to it, it should go into DevNet 8. But let's say the cutoff is A C D T on Monday. If no one speaks up by then, then we should just add it to DevNet 8. Thank you. as a quick note, is someone from Prism or Lighthouse there to speak about the implementation? If there's any complexity or anything we should be aware of before all the clients start working on it for DevNet? Okay. I guess the discussion would happen on the interop chat if anything. but yes, otherwise it's already in the specification and we should be to go. we have a specification ready for DemNet 8. Bannabus, do you wanna give us an update on when we want to launch it? Yeah, so we're aiming to launch it this week, but because there's just a bit too much chaos happening on DevNet 7 as well, as just clients not being ready on for DevNet eight and we had some repricing open questions still. I think it would be better if we are targeting sometime next week, early next week. I would say possibly around Tuesday. Okay. that sounds good. And just for general knowledge, what's the spec going to look like for DevNet 8? Is it the public DevSnack? What's the plan? how can operators onboard themselves and so on? Yeah, so I just linked the current spec sheet. and this is gonna be a name testnet. And ideally we would have a client release for every single client, but this would be an optional ask from our side. this is just gonna look like a previous name testnet that would be running for a few months only. So having it hard-coded in your client is not essential, but it would just make it easier for the public to get on board it. So ideally we would have the spec up by Monday or Tuesday on the day of the DevNet launches, and then we will have the Gloss for approximately a week after Genesis. great. And if anyone wants to be Genesis validators, for example, large staking providers, et cetera, who should they reach out to? yeah, Genesis there will be a few entities that will get automatic stake in the Genesis validator set. I don't think we're gonna have any onboarded Genesis validators for for this. everybody should probably just make deposits. we we're gonna have Dora up with a deposit option to to submit your deposits. Sounds good. Thank you. anything else, Glamsterdam related, before we move on to the next topic? Okay. the next item on the agenda is Hegota. So today is the headliner non-head, sorry, today's the non-headliner EIP submission deadline. so please do put a comment, especially if it's on execution EIP in the ACDE GitHub issue, so that it can be discussed next week. But today is still the cutoff date. that being said, we're mostly talking about EFI decisions. So this is going to be a proposal. A lot of times this is the first time an EIP is being introduced. It's not a CFI or an SFI decision. So we're not making decisions on what goes into the dev net, what goes into mainnet, nothing. This is merely a way for clients for people to introduce their EIP and for clients to start collecting information and having their opinion to arrive at rough consensus in the future. For sensitive topics, we'll definitely make our best effort to flag them when they'll be discussed in future ACDCs. But that being said, we have a full roster to discuss today. So let's start off. The first one's EIP 8359, beacon block reporting field. Hanibu, do you are you around to discuss it? Hey, can you hear me? Yes, go ahead. Cool, cool. So I'm proposing EIP 8359, which adds a beacon block body field for the validator client and setup reporting. just like to get this out of the way that this is not consensus impacting. but yeah, until we have formal verification, promoting client diversity is still important. but right now we don't have great data. today's data comes mostly from crawlers and and more recently graffiti watermarks, but those are insufficient. crawlers, they aren't exclusive to validating nodes. They have known issues with reach and peering bias, which can over-under-report client market share due to that. graffiti watermarks, user graffiti overrides it, so data can be either truncated or not included. and as of a couple days ago, only 60% of blocks report watermarks. and there's no insight into multinode setups such as DVT Vero vouch things like that. So this EIP introduces a 32-byte field in the beacon block body used to report the CL client, EL client, validator setup types, and client agreement threshold used to verify the correctness of the chain. we're still finalizing the schema, but at the moment this supports. Up to 28 setup types. A setup type could be running a standalone client, it could be running SSV, Vero, vouch, Obal, things like that. and it supports a of threshold up to six at the moment, and 14 client pairs. with up to thirteen sale client options and thirteen EL client options. and again, this field is information only and does not impact consensus if the field is malformed or contains missing data. Luca, are you here? Do you have anything to add that? maybe just that it's yeah, like you said, it's low in terms of complexity. I created some reference implementations. you can take a look at those here. Just so you have an idea of what it looks like. I'm not familiar with the format. Is it usually like a little QA session? I don't know how to Exactly. so we've time boxes, so about five minutes. So you still have a few minutes in case anyone has open questions. I guess first one I had to start off was is there some reason we can't just have stronger guarantees with the graffiti field that we have today? so it I mean you're working with limited space. so that in self is is is limiting already. and even with the condensed information that it it currently puts in, which is just the current client, most of it is mo for a lot of clients, I guess up to forty percent, since only sixty percent are are reporting. that watermark is overridden. or pushed out by the the the client's graffiti, the user graffiti. And it again, it y it you would need a lot more space to show multiple clients and the setup types, things of that source. yeah. Mm yeah, makes sense. does anyone else have questions for Hanibu? Not all at once. Okay, great. So then we yeah, we can discuss this on the ETH RD server. I'm assuming there's also an ETH magician's post. yeah, we can fill this. Yeah. All right, thank you. Yeah, thank you. next item on the agenda is quick slots from Barnaby. You have the floor. Hi everyone. let me share my screen. Can you see the slideshow, Harry? Yes, looks better. Okay, super. All right, so faster Ethereum, a quick case for quick slots in Hegota and Barnaby from IF Labs. at the larger point, I would say that faster Ethereum is something we care about quite a lot in If Labs, and we see quick slot as kind of a really important prong in in making Ethereum faster. So why does this matter? Like we we very strongly believe and and and can see that a faster Ethereum is more value to our users. when you have latency in the system, that's a cost that's paid in in different ways. So if you are able to reduce latency in different in different ways, you unlock many benefits immediately. So some of them are here. first you have better UX for users on the L1 with faster inclusion, so your wallet just ticks faster. you have fresher prices for on-chain markets as the oracle are getting refreshed at a higher frequency. You also get almost for free faster finality and a faster fast confirmation rule. Fast confirmation rule is already fast, but you can make it even faster with with faster slots, so that's really, really nice. and something that's a bit underrated, but but also is true is you because you have more leaders per second, because you have like more block producers. per unit of time you also increase the the censorship resistance and in particular the economic censorship resistance so how much it costs to to to keep a transaction out of the out of the chain. the takeaway from this I would put it is it just means we we we have more available block space. So block space is the main thing that we are that we are selling here. and and lower ethereum l lower latency ethereum is just more value to to the network in general and this value also does accrue to to if the asset. So here's like the quick one, two of the of the proposal. the first step really is to remove the hard-coded 12-second slot assumption where it exists, so both in specifications and also client implementations, but also in smart contracts that are deployed and infrastructure that that supports the the chain. and then second step: once we have removed this this assumption. proceed with a moderate decrease. And here we are targeting 10 seconds. So that would be our our anchor and our proposal. But I kept it as less than or equal to 10 seconds because I think it's also worth it to to push and see like how far we can go. But I but I think anchoring on 10 seconds at this point seems to be seems to have like the widest acceptance in the in the community that I hold so far. So why do this now? Why do this in Hegota? The principle I would follow here is just delivering value earlier. And I think slow time is one of these things where once it's live, the value is almost immediately delivered. Like you don't need to you need to change a maybe a lot of things like ahead of that. But once it goes live, suddenly things are faster, your AMMs refresh faster, you have more leaders, faster finality. So so I think it's it's just really, really nice. Like it's not something that we put in place and gives us like benefits years from now. Additionally to that, like I don't actually see a really good opportunity to to do like this one time cost of of removing like the 12 second hard-coded assumption in the fork after Higota, which is iStar. It's expected that decoupled consensus will be or at least is currently like the front runner for for for that fork. And this is like a a huge piece of work for for the consensus layer. from informal discussions with with the teams working on this, like it's it's not believed that coupling this with a a slot time reduction would be would be safe, unless the work of reducing that of of removing that assumption was done beforehand. And so doing quick slots in EgoTab means that we we open the door to more gradually like decreasing the slot time, perhaps in ISTAR with decoupled consensus that gives us a little bit of headroom. And maybe again in in JSTAR. so yeah, we we can just have value delivered continuously instead of no value for for a long period of time. So here are a couple of considerations. So I pulled the client teams, particularly the consensus layer client teams, EF protocol teams, other people in the in the ecosystem. This is sort of the the main technical blockers that that surfaced through these discussions. I'll go through them one by one, but with some thoughts on on where we're at with with fixing or removing these blockers. The first one is slot zero. There's a little bit more business logic happening on the on the consensus layer when when you move to a new epoch so that delayed some nodes. My understanding is that this is actively discussed. There was a writer by Carlos a few months ago and many client teams are are working on on optimizations already. There's of course the attestation and aggregation latency. So that's one of the key bottlenecks. This actually improved with EPBS moving some of that out of the critical path and then decoupled consensus. makes further headroom by reducing the size of the committee that votes on the available chain. something that came up is do we need to reprice data when we scale the the slot time? Because right now the the data is priced consistently with how much time there is for propagation versus execution. My understanding is that it's fine either way. Like if we need to reprice that's something we can do and and we've already set up like most of the testing infrastructure to to figure that out. But we can also probably scale the slot time in a way that we don't need to to do a repricing. In terms of contracts, many of them or possibly many of them are hard coding the the 12 seconds. So we are we're actually doing like a a survey with a Sourcify team on identifying this contract. And we we already have like some of the largest contracts that might have this dependency identified. So we'll we'll reach out to them. Same thing for infrastructures, for instance, block explorers, like is that something that they need to pay attention to? Most likely yes. I asked someone at EFASCAN, they said for them it's more load, but no, no breaking changes. testing requirements, so testing like at the fork, moving from 12 to let's say 10 seconds. I asked Parry, he seemed to say, yeah, we if we can we can we can do that. I mean it's it's doable. And if we do decide to to do it. compatibility with decoupled consensus. Actually, decoupled consensus in my sense was was built one of the design objectives was to move finality out of the critical path for the slot time. So I think that's actually a good yeah, a good thing. compatibility with ZK. there is like questions on the proving time in particular because there is some fixed overhead with recursions of of proofs. There's a couple of tricks that could help. One of them is Delaying the state route, like actually doing that as a proper delayed state route, not as like EPBS shifting the state route computation. But there's still, I think, some trade-off at some point between how much scaling versus how much latency we can we can accept. But I think we're we're far from the efficient frontier of that trade-off at the moment. and finally, I think post quantum is probably one thing that's on on top of many people's minds in terms of compatibility, but My sense again from talking to people involved with post quantum timelines and and work at the at the EF are that 10 seconds in Hegota would be would be perfectly fine. Yeah, so that's it. I think that's really quite a lot. But if I missed anything, of course, like you should reach out to to me. So thank you for this. yeah, please DM for support. Love to hear from apps, like how this helps them, if there's comments on on these technical blockers and and I left a few. references here and in particular we got started on on specifications for consensus layer and and execution layer. Thank you. Thanks. I think we have a few questions in the chat. We have like seven minutes still assigned, so let's take them. Dustin mentions continuous decrease in slot time creates ambiguous ambiguity and more disruption than figuring out a somewhat larger drum. is it true that both the main issue is various variable slot times at all, but also all the infrastructure assumptions have to be reevaluated separately for each decrease. Dustin, do you have to want to add something to this or is this ready for Barnaby to answer? No, I think that's that's ready for Barnaby to answer. Yeah, yeah, thank you for your question. I think this is sort of what I was trying to to convey with my opinion is that we are most likely never going to do a one time big jump of a slot time and then call that done. I think we always want to be quite conservative and and careful with with changing that parameter. I don't think it's too difficult to reduce the marginal cost of changing that. So we're not going to change it like every between hard forks or anything. Like we can still peg changes to to hard forks. but we can make it in a way that the first time is going to be a bit more painful. But then the next times will be will be easier in particular for contracts that are live online net and and client implementation. So so yeah I I Do think like last year when we discussed Amsterdam, I think there was a lot of pushback on moving from twelve to to six seconds. I don't see that improving in the in the future. I think the more we go on, the more we have like uncertainty over ZK or PQ perhaps, the more we'll be we'll be conservative with these changes. So so in my opinion, I think given this uncertainty, I would I would prefer to take the take the value early and and then work. on making future changes as painless as possible. And I think this is totally totally doable. Well well I I I wonder about that a little though, because like I I mean Ryan here mentioned and I agree with this personally, Joe, or a skepticism about it, is is twelve to ten worth it? So like I because you're you're eating a lot of the the disruption and the structural disruption and cost for honestly not Not that much better. Right. I think we I agree. I mean, obviously I was again pushing for six seconds last year, and I think this is still like a a target in my mind. I'm just no longer confident that we can do this much at at one go. And so I I think we should agree, and I and this seems to be like a a fairly widely agreed upon stance that faster slots are valuable and important. And right now I think the best way to to get there maybe ever is to is to get started and accept that yes we won't have more than a moderate improvement in Hegota, but at least we'll have an improvement. And and ten is better than twelve. And then possibly eight in ISTAR is better than still twelve in ISTAR. And then maybe even lower in J Star is is better than still twelve in in J Star. So I I I looking at the timelines I I feel much more confident going forward with with a moderate decrease, even that decrease to me has value already. Like twelve to ten is it's not insignificant. It's not twelve to six. but it is it is something and is something that that can be yeah that can deliver value to to the network. Like for instance the fast confirmation rule has gets actually a bit slower with with e PBS, moving from twelve to ten, like we are dampening a little bit of that effect of of EPBS Delaying some of these timelines. So I these are just fixes in in a way. But but beyond that, I think we we also have other places where the value actually gets delivered. there's one more question from Justin about gas limits and blob limits. Do we scale them or how does this work? Yeah, I think in the in the specs we have kept the throughput constant. So the gas limit and the blob count per block should change, but that's because the block will be more frequent. But this is not like this is really an EIP that changes only the only the slot time. And any other change either to the gas limit, to the blob count, or to issuance, that's also a question that came up. Like these should be separate EIPs and they should be argued for on their own. merits. So the way the specifications are currently done is all of the invariants are kept invariant. And if we do want to change the gas limit, we we need to make an active decision for it. Like this is not a a backdoor gas limiting please. Awesome. paraphrasing maybe a couple of comments or questions. how does this affect contracts? What's the effort being put into figuring out which big contracts, if any, rely on hard-coded slot numbers, slot lines. Yeah. I think quite a bit of effort. Like we're we're scanning basically the entire sourcified database of of verified contracts, but we already identified like a few big contracts where this parameter shows up. So over top of my head and two discussions that I had are Lido and Arbitrum. the Lido team has told me that they had already looked into this at the time of Glamsterdam when the earlier proposal was made. And they they need like a bit of room to sometime to to change the parameter, but it's not not at all impossible. and same thing for arbitrum. I think the parameter comes in for the the dispute resolution game in the bold. and these are two two big contracts. I I could pull a the the survey that we did. I think some of the other big contracts were eigen layer and possibly other staking related contracts but I think from a very initial look most of the parameters are governance are still governed by by some kind of of governance yeah I see yeah Dima do you want to yeah just a quick jump from my side so like even though twelve seconds is now hard coded and LIDA the plan is actually not to change the exact hard coded parameter. But rather transition to a timestamp based frames for the oracles, which is the only place where we use this twelve seconds assumption on chain, which means that we will just need to do one upgrade. And after that, like if you guys will prefer to reduce slot time further, there will be no action required from LIDA. So we are pretty supportive for the proposal. Thank you. any closing sorry, yeah, go ahead. For arbitram, we've looked into already the changing this duration, and then we have a second plan also that is more complex that we might want to implement instead. Awesome. Thank you. Any closing remarks, Banabi, before we move on to the next topic? No, other than let's do it. I think this is really important. And again, I I do think this has a a lot of support from the community. So yeah, I we should really just get started and and and look towards faster review. Awesome. Thank you. yeah, and please have a look at the comments later. I think there was quite a bit of discussion going on that we only managed to paraphrase, but there was important nuance. next item on the agenda is VOPS profile for fossil eligibility. Tomar, please you have the floor. Please go ahead. You have about five minutes. Yeah, thank you. I think it will actually take less because yeah, the EIP I'm proposing is informational, so it's Very much like it's just about making sure we agree on defining what frames are eligible to benefit from forcehole inclusion guarantees. right now it's pretty you know straightforward to establish how fossil works with just like regular transactions. it basically just like checks nonce and balance and it's all also it it's also working fine with transactions from like seven seven two. delegated accounts, but if frame transactions is SFI'd, and I yeah, I hope it would be, we need to define sort of like bounds that determine to determine like which frame transactions can benefit from fossil and will always benefit from it, even in in like a post DKVM future in which you know you have some nodes that might only hold sort of partial states like VOPs. and which you know trend transactions fall outside of fossil enforcement because I don't know, they touch arbitrary state during in the verify frame, for example, or or other things. so yeah, the goal is basically to agree on this boundary early, because applications, especially if you want applications with like immutable contracts, need to know that boundary up front so they can sort of like design their validation logic and and and and contracts so that they know the transactions coming out of them will always be eligible for for sole in the future. so I think it's kind of important to agree on on that that boundary, but it's non-consensus critical. it it's and it's yeah again informational. Awesome, thank you. are there any questions for Tomar? Okay, thank you. next item on the agenda is EIP eight one four two web columns propagation. do we have Camille on the call? Yes, everyone. Yeah, please go ahead. Yeah, giving a seek. Yeah, yeah, we've allocated roughly five minutes. Okay, yeah, can you see my screen? Yes, please go ahead. Okay, great. so yeah, this is Camille from EF networking team. Yeah, we'd like to PFI blocks in blobs. yeah, the high level idea is we put execution payloads into blobs and then we yeah, leveraging existing peer DAS plus cell level deltas for payload propagation. And why we do that is to get efficiency, so just to enable faster payload broadcast. Also, yeah, we consider this to be quick win because we reuse existing peer DAS machinery without introducing new gossip design into the protocol. And yeah, this also gives us the flexibility because it kind of provides the natural path forward towards ZK testers future, which would not require will not require. The full payload after our mandatory proofs landed. Yeah, we plan to do this in two phases. phase one is basically what we're going to focus in Hegota. Yeah, the plan is to deprecate execution payload topic, and instead, peers would subscribe to all column subnets and then use cell level deltas to fetch the execution payload. So visually it's gonna look yeah the following way. So Yeah, we have like custody columns and non-custody columns. For custody columns, we still use yeah, we still fetch them in full. So yeah, we use we use cell level deltas and we advertise our I want bitmaps with all ones. So that means we're requesting the full columns and for non-custody columns, yeah, we advertise only the bits. Well, we only advertise that we request the bits of the rows that correspond to execution payloads. And yeah, this kind of nice because that way we already kind of using existing PRDAS columns that we have, yeah, we can leverage them to take advantage of erasure coding to propagate payloads faster. And this also gives us some flexibility because, for example, well, the execution payload rows they cannot be well, in contrast to user blob rows, yeah, we do not pre-propagate. These blobs on Yale, and they only sent by the builder when kind of the bit is accepted. However, this is not the case for the balls, and balls can be propagated sooner. And yeah, with this framework, yeah, we can advertise. I have I want bitmaps for balls sooner than we do for the rest for the remaining execution payload rows. so yeah, that's phase one. And phase two is actually when we actually have the mandatory proofs. And when this happens, yeah, validators they don't need the full payload anymore to yeah, to a test to verify, and and then and they revert to custody only column subscription that we have today. And what is good with this design is this could be done via just single parameter change, so it's gonna be a very simple change, and Yeah, the other peers that well they still need the full payload, they can consider keep subscription to all columns and kind of use this cell level deltas mechanism to kind of reconstruct the full payload if they want. Alternatively, yeah, if by this time we come up with better gossip strategies for these large messages, yeah, we might just switch to these strategies. yeah, we've run some simulations basically just comparing Yeah, status quo, what we have today. So what we would get with propagating execution payload using Gosips app, compared with the strategies that I described, where we use basically columns for that. And yeah, we also used your reference C P2P C broadcast propagation for comparison and interest could you wrap up in the next minute so that we still have a few minutes for questions. Yeah, that's my last slide. So yeah, basically we see the results. So we see that yeah, with columns we propagate much faster. With EC broadcast, it might be a bit better, however, it is not as flexible strategy because when we switch to only custody column subscription, then yeah, yeah, this is not really doable with EC broadcast because it requires the full payload. Yeah, that's all from me. yeah, you can find the Ask questions in Ethereum additions or yeah, check the APM. Thanks. Thank you. yeah, Potos, go ahead. Yeah, so I have two questions, which are the same questions on two different limits. so ePBS gave us this thing which which is that we can propagate blobs throughout essentially all of the slot. on the start of the start of this propagation time is essentially when as soon as you see the the consensus block. The builder can start propagating blobs. at least this the columns, complete columns. I suppose this is not going to happen anymore if now this these columns are going to have information about the payload that they want to hide until they are safe to propagate. So this takes away some part of pro blob propagation at the beginning of the slot, unless you only propagate these cells. Now the second part is the end of the slot. This seems to me also to take away most of the end of the slot and the separation between the payload deadline and the blob deadline at which the PTC needs to attest. Because the PTC needs to attest for the timeliness of the payload itself. And that timeliness is different. Now to today is set at six seconds and the blob deadline is at nine seconds. I don't see how the PTC will be able to carry this if they are coming together. Yeah, for the first part, I guess like, yeah, we can. Well, we cannot yet indeed prop pre pre propagate pre-propagate execution payload blobs, yeah, before the beat is kinda accepted, which is not the case for buffs as I described. I didn't really get the second part. what do you mean? Well the fifty c needs to get all the blobs bef that they need to cast it before today nine seconds. But they need to get all of the payload before six seconds. So there's if the payload is propagating together with blobs, then they just will this will force blobs to be before six seconds for the PTC to be a testing. Yeah, I guess we need to just specify which part of the blobs we have which deadline. because yeah, it's just a machinery. I mean we still have like It's just another way for propagating execution payload. So we have the same assumption, we keep the same assumptions for the deadlines for receiving the execution payload. It's just, yeah, we use the reuse the columns for that, for propagating them faster. Potentially, this would allow us to actually lower this deadline. Terrence, but could you be quick? Yeah, I was gonna add on top of today. It sounds to me the fundamental differences here is that we need to separate the market space, right? Because today we have blobs that's used by rolls, but then this also introduced blobs. So therefore we cannot mix the two blobs together because because different deadline, because different pricing and stuff like that. So yeah. Yeah, right. yeah, the AP addresses that. I guess this also kind of would be introduced in phases. yeah, there were ideas like maybe just well everything any anything that's related to pricing maybe comes next and maybe not in the H star, maybe later. That's still T P D. yeah, we will raise it. I guess maybe in cut the upcoming P T P calls or yeah. So Thank you. I guess people can reach out to you on the peer-to-peer call or on ETHRD, right? Yes. Great. Thank you so much. next item on the agenda is Rotas. do we have Chaba on the call? Yes, I'm here. Yeah, please go ahead. You also have roughly five minutes. No slides. So I'll be just talking. Yeah, so it's EIP eight seven one. LODAS distributed blob space reconstruction. So what we target here is is a weak point of of PLDAS, which is how reconstruction is done in supernotes and in supernotes only. reconstruction is is CPU intensive and it also scales in a visible with the blob count, two properties which are just not nice. And then that is the other thing that reconstruction requires super nodes. We do have super nodes, but it's still not nice to rely on the fact that we need supernodes for this robustness. So the proposal is to find a way to distribute the the reconstruction, the broce reconstruction. And we would do that with low low topics and use server messaging and that so partial messages. what we would do is allocate uh's to nodes, just one row to each node, no need to do large allocations. And also no custom requirements, so it would be like a secondary reliability mechanism, not not like in the original proposals of DAS where we have column and row allocation. And also this allocated row would be rotated to balance the load. So that would be a mapping permutation from Bob IDs to to the IDs in each slot, and that would decide what goes well. the yeah, elements of this were coming from Fuldas from from the P2P extension for pass messages that we are using for the on the columns. And yeah, the the overall effect would be that super nodes would be able to focus on on a single law, do the reconstruction for that. so we would divide kind of the reconstruction phase for supernotes into two phases. A first phase when they are just focusing on their allocated law. everyone on their own allocated law and they would share this. And then a second phase which would be basically what's happening now, which is again a reliability mechanism behind the the distribution. So that first advantage would be that so that supernotes would would do much less work in typical conditions which is they would just deconstruct one one law. And you can say supernotes could have many calls and they could do all these things in parallel, but it's still CPU load. So and actually they are not doing it all in parallel. So this would just nicely distribute the load. The other part is is non-supernodes. So non-supernotes could also chip in into the construction. they would collect notifications in these low topics, so the Yeah, maybe an interest part that I didn't mention is that these row columns are we are not pushing messages on these. These are just notification based. So we have a bitmap exchange. So they could collect on on these allocated rows and and participate in the reconstruction. again, this would be more or less a voluntary or as a delayed mechanism in case supernotes are failing for one reason or another. what this is not, this is not Full DAS. So this is not sub-denial cell sampling. The sampling is not changing, it's still column sampling, is the same. there's also no columnized encoding like in Full DAS, so we are not changing kind of the column structure. This is boiled on top, relatively small change and aims to to use the CAP load to make this in the system more robust. that is also a related thing which is typically I2 nodes looking for specific blobs. This is not helping them directly. If they are super node because they have less CPU load. And I was leaving in a part discussing this in the in the IP. we can also, but it I think it needs a bigger discussion how we want to address whether we want to address that kind of inefficiency when nodes are looking for specific blobs. Yeah, that's it mainly. Thank you. any quick questions? Great. then please reach out to Chapa if you have comments or yeah, you use the EIP to discuss. Thanks, Shama. next item on the agenda is tapered issuance bond. do we have Jerome on the call? Yes, can you hear me well? Yes, please go ahead. Awesome. You have roughly thirty minutes. Wow, that's that's a lot of I just requested Three minutes if I remember correctly. let me just find the button to share my screen. I'm I don't think I can share my screen though. yeah it is. Okay. All right. Good morning and good day, everyone. I have dropped a link to those slides in the in the chat. I'm here to present you EIP 8363 called Tappered Issuance Burn. there's a link to the EIP in the slides, and there's also a link to the if magician tread if you want to discuss this in in further detail. So, as a quick overview, this this proposal primary goal here is to remove the issuance mechanisms incentive for stake growth once the staking ratio exceeds 50%. It accomplished this by deducting a burning, deducting and burning a tapered fraction of idealized validator rewards at each epoch boundary, so that the net staking yield declines linearly while the staking ratio with the staking ratio and reaches zero at 50%. So, as you may know, Ethereum has a history of regularly changing its issuance schedule. this is not the first time we're discussing an EIP to reduce issuance, even under the proof-of-stake regime. And I'm very pleased to have the stage right now to to present this to you. So, why do we want to change the current curve? First, there's a priori an endless Incentive to stake because under current issuance curve, the yield never drops below approximately 1.5 percent, meaning the incentive to stakes never organically switches off. Whether stake growth stops here only depends on stakers' risk premium and the opportunity cost of other sources of yield. Those also those other sources of yield the protocol can neither observe or control, and the risks. The staker risk premium keeps falling, falling as the staking infrastructure matures. Those this endless incentive to stake as security and centralization risks, notably that high staking ratios degrades Ethereum securities by concentrating stake. It's also creating moral hazard where large operators become too big to fail. This dynamic forces independent solo stakers out due to negative dilution adjusted returns. And furthermore, with most ETH being held at custodians and staking services, the social layer, the EV that are not at stake, loses their ability to effectively coordinate a fork for social slashing, which is our last line of defense. This also has a consequence regarding the moneyness of ETH or the role of ETH as the native money of the blockchain. The current system acts as a continuous dilution tax on unstaked ETH, forcing holders. To stake simply to avoid dilution. This pushes liquid staking tokens and other staking derivatives to displace raw trustless if as the working money of the ecosystem, which introduces counterparty smart contracts and governance risk. So why are we proposing this for inclusion on eight star? Well, if our target is to prevent 50% at stake with current trend, the 50% of the supply at stake will likely be crossed in 2008, in 2028. So doing it later is a decision to choose a trajectory that we should avoid. Now is the opportunity for a smooth transition towards a better issuance curve. So this is our motivation to propose this on HSTAR. The window closes on its own, and the reform gets harder every month because we have more and more if at stake. The proposed solution is the following: we are introducing a tapped burn function. That has a 50% saturation point. This allows for a market driven equilibrium regarding the if at stake, and also micro incentives remaining untouched for the behavior of the stakers and duty specific deductions. This has the advantage of low complexity. We have a proof of concept implementation from Prism that's about 300 lines of codes. And we also have a transition plan because if we act now, we can smooth the transition. So here you see an animated transition for an 18 month is phase in. This is softening the transition for the actor that will be impacted, and that will be also two years in practice. because between the time that we decide to include this EIP and the time that this EIP goes in force with H star. there will likely be about two years. I wanted to keep this presentation short and invite people to read the IP as it was published quite recently. And there's also a link to the Eve Magician thread for those of you that have not seen it. The topic is obviously complex and it's inviting intense, very intense reactions in the heat of the moment. we are going to keep on explaining and answer all the inbounds we are. Because for now we perceive that there's a lot of misconception and and good feedback that is being brought to us in terms of what needs to be clarified. As time goes, we hope that people will form inform opinion and hopefully converge to the right thing for the greater good of Ethereum. So we're going to keep collecting feedback and continue consulting the community. There's an additional slide here that show key figures you can also peruse to to sum up the thing. and yeah, that's it for me. I only prepared for three to five minutes. Thank you. there's already a couple of comments and questions on the chat. maybe we can start with the one from Barnabas. do you want to read out your comment? Yeah, so my main question would be whether the goal here is to taper the issuance or to make sure that we don't reach 50% more state, or is it both? Because I think we could we could actually achieve keeping the issuance the same as what where it is right now. but just basically limit the issuance in case that we do achieve more than fifty percent. I I'm not sure I I get what you mean by by that. You are are you suggesting that we we limit the inbound of new validators? I did I get your your comment correctly? Yeah, something like that. I'm not sure technically how we would do that, but I'm I'm sure that we could think of a way to do that. So you can basically only deposit a new validator in in case we reach fifty percent of the stake ETH, the only time we would basically the deposit would reach the beacon chain contract is if someone exited. so that's that's indeed a possibility to actually cap the fifty percent if at stake. but this has also consequences or on the capacity for new validators to come at stake, obviously. so keeping keeping access to at stake status, neutral and accessible to everyone, is also a desirable property. So this was this was considered a less desirable approach. Than the the tapered issuance during our discussion. And it also opens up on different forms of attacks, such as being the first at stake and growing your stake, while the others will have to rely on social coordination to remove you eventually. So that's interesting comments. I I'm happy to to give you a deeper analysis in DMs as well. Yeah, my main question would be what is the actual goal here of A to three sixty three? Is it the tape predictions or is it the 50% or is it both? So it's to limit the stake ratio glow growth at the fifty fifty percent state. That's that's the primary goal that we are looking for here. thank you. the next person is Oyson. please go ahead. Hey guys. one of my main concerns with making a competition to see like whoever can stay viable at like a lower price is that the Nakamoto for the chain will really decrease. And I know it's subjective, you know, will the Nakamoto be low and high sticking ratios or not? But like firstly, Jerome, do you think that this proposal will make price competition and will kind of, you know, reduce the amount of operators that make up a majority of the staking set. And do you think that's a problem, if so? Yeah, it's so I have I have my own reservation on the usage of of the Nakamoto coefficient. I I'd love to have more data points and and and you know data different versions of of the Nakamoto, notably how easy it is to challenge it and and and grow it or lower it depending on the accessibility of the network itself. I I I'm I know this coefficient is very dire to you and you are often time bringing it up and I think it's a good time that we should consider actually publishing and and going behind a proper Nakamoto number so we don't have to guesstimate what it what it is and what it will become depending on different implementation of of proposal that we consider. Now when it comes to the diversity of the of the validator set itself, it's to to put it to put it bluntly, it's very undecided topics because when you look at the reservation yield of different categories of stakers through the three different studies that we have at hand, it's genuinely undecided like who goes out first and for which reasons. there are interesting points to to to look at, nevertheless. we have good consideration regarding the solo stakers. For from our point of view, the an issue and change should by all means protect the solo stakers or make them viable for as long as possible. The comparison point that we have is that the current status quo is Whatever we do pushing the solo stakers out. So if our last our most important categories of stakers that we should protect is the solo stakers, we should start by considering that the current issuance curve is not the right one. now when it comes to what this kind of proposal will do to the solo stakers, it's a matter of how much those solo stakers will perceive their personal operational risk compared to splitting it to a service providers, which introduces a new risk for them, which is the staking service provider risk itself. it's undecided if we will or not reach a state where the yield that is being given to the stakers is enough for the solo stakers and not enough for users to carry the risk. of stacking service providers. in which case we are in the base best of both worlds. we have reduced these ones, capped the 50% ratio of if at stake and also preserved the solo stakers. Analyzing the reservation yield is an ongoing process. we are taking feedback from the community on the on the matter and we are also Taking a lot of time educating people on their perception of what the reservation yield is. Behind the yield, there is the dilution adjusted yield, and there is also the taxation that you get on the yield in most jurisdictions. and we think that the burn approach is the best one to limit the impact of taxation, which at the end of the day creates a real yield approach for the solo stakers. that's much harder for them to bear than using staking derivatives while keeping the the the the dilution low. So the the framing that we use is that we consider the the staking yield that is actually given by the curve, corrected by what the stakers will have to pay in terms of taxes a priori and dil dilution adjusted. in which case the the tapered is the one that that perceived highest result, net result, for the longer time for the solo stakers. Who and sorry for the long answer. Yeah, all good. Keeping my side short, I'm only gonna point out two pieces. One is obviously it's important for us to have solo stakers, but I think if we as an orger like, you know, trying to think about what is Ethereum's like crop subjective, really the you know, the left side of the curve or like the fat tail is the one that really decides who controls and can use Ethereum. So this is how many groups make up. 51% of stake, give or take. And I agree with your comment about, you know, that there's more than one way to cut that number. It's not only like stake weight alone. but also, you know, on the solo staker side, there's also home stakers, which are kind of, you know, smaller than solo stakers again, people without 32 ETH. These guys, because they're running other people's ETH, they are making a real yield even under the current curve, even if it goes to higher than like most people think it's going to go. so I think the, you know, if we're from both sides looking at kind of the the big, you know, the big operators and then the very long tail, they are not as vulnerable to this zero real yield type of situation that like is being put forward as like the the main blocker here. And I think we're over indexing on what's somewhere between two percent and like zero point two percent of the network, whereas I don't know, the vast majority of the network is is not in this situation and will be priced out if we go this other route, which I think is not good for Ethereum security. Thank you. Greg, I think. Yeah, so yeah, I wanted to mention that I would kindly request from authors to withdraw this PFIn Hyakota 'cause I think this CPE arrived two days ago. It presented a new curve that no one knew before. And yeah, I think due to this being a very kind of controversial and very big change. I think that starting considering it for Hikota will create many issues. first of all, most of us were expecting any issuance proposals to be for future hard forks. So in particular like at TCC in April there were some discussions in Cannes and it was really no not particular carefully discussed like we have A very generic discussions around issues. So I think this doesn't give time for people like to prepare better and/or like give counter proposals about issues since the common expectation was that this ones will be discussed for later forks. So now having one EIP for Isans for Hekota will create this kind of confusion. Like it will be the only option. So it will appear like either this EIP or no issuance change at all. And that to have like I think not so good like not so objective like give not so objective image of what's going on. and yeah it seems that like having only like this CIP appearing now it's too late to start having you know constructive discussions since like for Hikota we already have like 40 IPs proposed. Mm, a lot of them have very useful features for for Ethereum. We have mess spent so much time working on them like everyone, and having like issuance discussion dominating the like the next one or two months for Hekota, I think we really kind of under like fill under the rather many useful things that people are working for a long time. For example, like we go we offer two APs for Hekota and we prepared them like since the beginning of the year. So yeah, I think that having now a new IP for such a topic, such controversial topic, to kind of get the whole discussion on it, it it will not be a good process. So I think it would be better to just like we could of course have the whole discussion on the specifics of the IP, like where everyone agrees or not. but yeah not having it by as proposed for inclusion for Hickota. yeah, and yeah, on the specifics of the AP I would agree with the previous questions, like if the goal of the EIP is extreme staking ratios, then of course you don't need to change the evolution's curve. So I think that there is a mismatch between the assumed problem to be solved and the assumed urgency to exist with the proposed solution. And of course, yeah, there are several centralization concerns that have been already made. But My first point and main point, it's not about the details of the AP, but requesting to withdraw the proposal for inclusion for Hekota, and then we'll have enough time to, you know, interact and have constructive discussions on it. Well, first off, Greg, thank you very much for for sharing your your concerns regarding the time left between proposed for inclusion and consideration for inclusion and so on. yeah. So the the curve that we presented was more pre previously shared at different workshop groups, I think notably in Cambridge by Paci. I have to I have to check this out. But indeed we got we got taken by the time and we get we we got we had we got we have to act while the we thought in in introducing this PFI that we have to act before the situation becomes too dark and too complex to fix. because once it's too complex to fix and and too too too expensive to fix the the cost of doing it may just be something that we completely put on the side. in the publication of the the straw map roadmap in late jan early feb the the issuance reduction was initially scheduled for i star i think that was a bit too too optimistic considering how much if was going at stake. The the arithmetics is advocating In our view against delaying this change. now I've well noted your your request for us to to withdraw this and we will think about it. but yeah, we have to consider that the the Windows is also closing on its own. So delaying is accepting that we are either never going to change and accept the permanent risk on Ethereum of going beyond fifty percent of if at stake, with all the consequences regarding security and moneyness for if or if we are going to start having an intense discussion now. we are welcoming the feedback and I I know many people have posted on in the in the in the in the information thread which is really great so that people can start to make a more informed opinion and also help us twe tweak what can be tweaked and we want We won't be pushing this as a programmatic proof of work or some kind of previous example of controversial attempts. but this is also opening the the the window for having those discussions. And the fact that we are having it now is very positive I think 'cause it makes people realise that the problem actually exists. Yeah, but the the point is that D CIP is not only addressing the high stake ratio issue. So if if the only thing that DCIP was doing was address this high staking issue, which we could discuss, of course, if you want, but okay, there is some entry queue, so you could say that you know, according to this entry queue, in two years after three years we can reach this point, and because this is a problem I have a way to fix it. That could be the case, but DCIP is doing much more than just this, because it's it completely redesigns the H1 scare. redesigns the H transcare about 10% it's taked, 20% is staked, 30% it's taked. And this is completely not necessarily about like the future staking ratios. So if you had an EP about this, I think that would actually be quite a good idea instead of you know speculating on what is going to happen about the future staking entry queue to have an AIP that from now like proactively sets something for the future that does not allow something happen but this is not the case here. So here we have an EIP with a full issue redesign. And this is presented just two days before the end of the window while no one was expecting actually that is runs would be considered for Hekota. So this I think it's very very I don't know a bold move. So yeah it would be great if we could just you know we we can have discussions about this IP but not proposing for Hyakota. one quick comment regarding the main objective of keeping via the the issuance curve the amount of if at stake at fifty percent. we will gladly produce analysis of the previous request the previous comments on regard from Barnabas regarding why not do just end of the entry queue after fifty percent. and why we We prefer to do it via the the issuance curve. one little note is that if we want to achieve this with the current proposal, it's also completely possible to get this benefit straight away, with a much lower impact, with a much longer transition, in which case you get the the zero percent of if at stake beyond fifty percent right away. but the transition is much longer and thus less less impacting the yield curve prevision before the fifty percent of course. So there it there's there's different way we can approach that and we are glad to get so many feedbacks and and concerns being raised 'cause it helps us shape the design. there were a couple of comments. Potos, do you want to maybe speak up about your comment? I'd like to add that I will personally commit to answering all the comments on the if magician thread. it's taking some time, obviously, but if you have any things you want deeply addressed, drop it and expect me to to deal with it. Yeah, and maybe just a note on the process as well. yes, the deadline has passed, but if people want you can still propose changes to the existing EIT. the decision is not being taken away from you that way. And the the PFI decision is i it's not even a decision, it's just a proposal. if anything, CFI and SFI are the real decisions that would be made and those are still weeks, months away, if anything. any other comments before we move to the next agenda item or anyone who's left a comment and wants to speak up or have it addressed? the only thing I want to say is that I agree with one of the comments that got lost in the chat. that the decisions on such types of things should definitely not be made exclusively by developers, and the community sentiment should be taken into account. And as far as I see now, the community sentiment is highly against the even the basic idea of the proposal, not Just the form of the proposal. So it would be great if we would be able to take such a thing as community response into account, because in most case scenarios, the response from the community is a good way to understand what's going to happen if we do not listen to that. Yeah, that's a very pragmatic and important observations. nevertheless forty eight hours of barrage fires and outrage on algorithm that favours the most extreme takes is not a good indicator of what the community actually think. This EIP is actually a really good occasion for people to rethink what their conception of issuance is, what their real terms post dilution, post taxation is and get to form informed opinion on the matter. and not jump into conclusion too fast. I'm a community member, I'm a solo staker and a reasonable individual. I think this topic is very important and too important to be left to misconceptions. So it's a great occasion for us to rethink again what our security assumptions regarding the Ethereum purple stake is. but also what our monetary policy is and should be to pay for our our security budget. and yeah this is this is a good time to do it and it's part of the strong app roadmap as well. So I I get that many of you that express their opinion vocally here are against even considering that for H star. but The debate is also positive and will help us all together converge to what's good, what's the best for the greater good of of Ethereum itself. Thank you. Ansgar, you had your hand up. Do you want to say something? Yeah, I mean, I'm not sure. I just want wanted to basically reiterate that in my opinion at least it like the one thing I worry about is that clearly like many people in the community are quite opposed to this change. Now I personally I mean people know this, I've worked on this in the past. I personally actually am quite concerned about increasing stake rate and Do in principle think that a change like this makes sense. And nevertheless, I don't I think it's it's clear that something like this could never be decided against a clear majority kind of like opposition of the community. So I just want to make sure that for people that maybe are worried, that are not so familiar with the process, that are worried that there is a risk that this will be basically pushed through against the community or something, just stating it in these terms. I would just say that I in my opinion at least, of course I also can't speak for Orkodefs, but in my opinion that is not a risk. I think to me it is clear that a prerequisite of a potential ac acceptance down the road would be that in the process of that conversation, kind of like the overall perception would shift and and people would be more open to this change. I think yeah, so so I just wanted to basically say this because I I I think it is it is otherwise of course very corrosive for Ethereum if there is a a Perception or even just a concern that potentially a a device of change could be pushed through against a a majority community opinion. So even as someone personally very c concerned about the topic and and and and open to a change like this, I I still wanted to to stress that yeah and I want to reiterate my previous comments that I totally agree with you on the matter. and I I lived long enough in the ecosystem to have seen the DAO hack and how the the coin vote and the hash hash vote happened. there are many ways of properly gauging what the interest of the community is regarding this change. and there's by noming nomin an interest in myself and I think the rest of the I think I can speak for the rest of the offer here, to to push this through in any in any way. Like we are inviting discussion and getting feedback, although we are pretty happy with the design we have so far. so it's great to see people giving us counter opinions. Right. I'd like to time box the discussion here, if that's okay. We have two or three more EIPs being proposed, so I'd like to sign some time for that. yes, thanks everyone for being really civil. we have an issuance channel on ETR and D. There's an each magician's thread. there's multiple places to be involved in the topic. please do get involved. next item on the agenda is from Oysin. We have anti-correlation attestation penalties. I think he had an update to present to the existing EIP. Yep, give me one second. Okay, guys, think you can see my screen. cool. So just wanted to keep this pretty short and give a small update about a tweak to EIP7716, which is an EIP to increase the inactivity penalties when a larger amount of the network is offline, because right now it's flat. So there's not really a big disincentive to be staking in a very centralized solution that might go offline. there is obviously disincentive for slashing, but we don't see that. But if we had a you know nonlinear disincentive for inactivity, that the hope is that this would encourage people to run on minority clients, not run in the big data centers, run the biggest operators and things like that. The TLDR of the adjustment is I started to model the EIP as it was written. And unfortunately the like change wasn't significant enough. It it was Pretty much a rounding error. It was like within 1% of the existing situation. On this graph, there's a green and a black dotted line. That's the current situation and 7716 as it was drafted. So instead, I've played with the numbers a little and how it works specifically. I can get more into the weeds, but ultimately it bumps the penalty up a bit. You can see up here roughly what it would be, and I'll show some examples from history momentarily. But like the the worst possible case scenario is if 33% of the network went offline for a full 24 hours, these people would lose a bit under 0.4% of their principal, which on the current curve is, I don't know, two or three months of rewards. in practice, though, that's an extremely large large outage and not really likely to happen. so I'll talk about that in moment. The other small thing is the original 7716 included a focus on head vote accuracy. But that can put us raised some concerns that if like the you know builder or EPBS pipeline was having a bad day, that this could be a bit of a disappointment that a testers would get kind of caught up in that. so this instead just focuses on source and target. So you have a full epoch to get included, and it doesn't really matter if you have an in incorrect head vote. looking back at the chain outage, I picked three different outages. It Just kind of so happens that most of the visible correlated failures happen with client failures. Sometimes there are others when there's like data centers that go down, but some of the biggest have been these three. Bessu had a halt, Nethermind had an issue, and Prism had an issue. if you look at like kind of the this as drafted column, this is like 716 before my change. It was kind of a 1%, maybe a 4% like difference now under this one. It's kind of a 2x or a 7x or a 22x difference. 22x maybe sounds like a big step up, but in practice it's not really a huge change. What this would mean for people that were affected in it is instead of being 2.5 hours of attesting to make your money back that you lost, it's now 2.4 days. So still relatively modest. You're like, okay, I lost two or three days for it. and then the questions I kind of want to ask people a little bit is, you know. Are these new parameters aggressive enough to like incentivize a change? If somebody loses a day or two's reward, are they gonna just, you know, ignore that? Or will that be enough that they'll be like, damn, I probably should be running a minority client? a related one is kind of how high do you start to pump these parameters that you have like perverse incentives that you know don't do what you want and encourage decentralization? Because the like time to recovery can matter a lot here. Where if it was extremely severe, all of a sudden people are like, no, let's just pick the centralized operator who can rectify in like a couple hours instead of twenty-four. so there's you know, a limit. We can't kind of you know pump this up crazily either. And the last question is Are there any other concerns, queries, feedback about this IP EIP that would have the community be more supportive of it and more interested in pushing this forward for Hagoda? That's pretty much me. I have some links here and I dropped the slideshow in the chat. I'm happy to take some questions. Thank you. yeah, Terrence? Yeah, I'll be quick just almost all the time. How does this work when there's an activity? Do you apply both simultaneously? So just today, I believe like we can reach two-thirds under 14 days. So you finalize something again. So would that make it faster? It's a good question. this has a cap which is designed to kick in at exactly thirty-three percent offline. So it it is cumulative, like it's on top of the inactivity leak, but it's much smaller than inactivity leak. The inactivity leak is is pretty severe. I think you can see it here on this slide. if if you get to the kind of inactivity, that's much more the contributing factor. But yeah, this this stops after thirty three percent. Awesome. Thank you. We have three more, four more EIPs to be presented. so the TLDR is if we can't get to an EIP today, we'll do it at the next ACDC, but it's already within the deadline, just to say that. And if anyone has to drop out, that's perfectly fine at the at the end of the call. but that being said, we have two EIPs, BLS withdrawal credential, retirement and balance sunset for retired BLS validators from NC. is NC or someone from the Lodestar team available to talk? I'm gonna share my screen. Can you see my screen? Yes, please go ahead. Right. So the high-level idea is to tackle the existence of the 0x00 legacy validators before they become a bigger trouble when we transition to PQ. And the vision, like the solution, is split into two phases. So that's why there are two separate EIPs. So that it will be more flexible or easier to discuss this way. So since 0x00 validators are pretty old, and maybe just like a quick recap on what this does. So basically it has a signing key and a withdrawal key, both a BLS. And the signing key is for signing the regular validator duties, and the withdrawal key's sole purpose is to sign the BLS to execution change so that it can become a zero x01. Validator. And the property of 0x00 validator is that it doesn't have execution address. So that means that all the withdrawal requests doesn't apply to it. All the partial withdrawal sweep doesn't apply to it because it doesn't have a address to withdraw to. The protocol can eject that validator, but after that validator is exited, the fund still remains on CL side. So it's a w really weird interaction this way. So to some high level stats today in the on mainnet, there's still around nine thousand there's still hold zero zero zero zero credentials and less than nine thousand if you just exclude the ones that are offline for more than six months. And ever since the introduction of BLS execution change, which is Capella, more than is around more than 500,000 validators have submitted them and to convert into 0x01. And the key takeaway of this page is basically that the BLS execution change, we're still seeing two digit usage every month. And we are still seeing new zero x zero zero buyers being created. So zero X00 violators doesn't cause a lot of problem today. just like some minor troubles. So for example, like protocol cannot remove a zero x00 violator. There's no way to withdraw that fund to anywhere. And also the client teams needs to maintain like the BLS execution change mechanism, like all the gossips stuff and the up. pool and stuff like that. They all need to maintain. And 000 validators, they don't submit BLS to execution change, maybe because they're lazy or ignorance, but it's also a possibility that they lost their sign their withdrawal key. So that they can still they still hold the signing key to do the validated duties, but they cannot submit the BLS to execution change. to become a zero zero one validator. So why I thought about this to this proposal is because when the PQ comes, every from what I've seen so far on the PQ validator registry proposals, every single one of them requires every validator to s perform certain action. Maybe is to submit their XMSS key or a certain variation of it. But the gist of it is that there's an action required by each validator. And if that validator doesn't act accordingly, I think it's in the best interest for Ethereum to eject them. While 0x01 and 0x02 can be safely ejected and gets the swept to to the EL side, zero zero. doesn't have a clean way to handle this. So it's a very bizarre thing because there's a couple approaches that I have thought about like how to deal with zero zero zero validators during the P2 transition. So if we do nothing, that means that those validators funds would be frozen forever. Because the BLS execution change is not PQ safe. So there's no way to withdraw out to convert the validator and first to withdraw those funds. Or we just delete them from the registry, which is a very brute force way to deal with them because it's basically like confiscating the funds, just like drop the balance from 32 E to zero E. And Alternatively, I've also thought about like maybe set up a PQ version of BLS execution change, which is a headache because you need to spend time on the research and the engineering stuff. But also you are basically continue to maintain this capella tech debt and convert into a PQ tech debt. I think PQ is a an excellent opportunity to get rid of this, but if we go the other way, then we are continue to maintain this. And the maximum usage of this PQ version of BLS execution change is just the n that 9,000 violence, which in my in my opinion doesn't make too much sense. So the proposal here is basically first the first step is to retire, which is to force exit all these like zero x zero zero validators so that they will enter a stage where they exited and their funds will still remain on the sales side. And in this stage, there's no rewards and there's no penalty applied to them. And They can still unfreeze those funds by just submitting a BLS execution change. It's a pretty straightforward. And then the second steps to drain so that the balance will decrease over time slowly, so that the goal is to get all of them to have balance of zero by the time we transition to PQ so that we don't have this like cliff That drops 32 ET to zero ETH like at one fourth transition. But like sorry to stop the presentation, but could you quickly wrap up so we still have a few minutes for questions? we're already over time and I'd like to let people Yes, this is like my last slide. yeah, so basically just strain them to zero so that like by the time PQ transition comes, it's an easier decision for core devs to drop those validators in a safe way because there's no more funds remain. And the entire proposal is very simple, just like one ePOR transaction step and one branch in the deposits. and then also one function just to decrease the balance over time. And in exchange, we save a lot of time not needing to discuss what to de how to deal with zero zero zero validators when PQ comes. That's it. Awesome. thank you. I saw a bunch of messages from Portus, Barnabas, came in. Do one of you want to speak up or Justin? Yeah, go ahead, Popus. I I I didn't understand the what do we gain from this? so I do get the point that perhaps we want to deprecate zero zero zero, and and that's an easy change, which is don't accept any more deposits after after a while. That's a clear indication that you shouldn't be depositing validators with a zero with a zero BLS credential, but Like the exit, the force exit, the the churn, like this is all complexity that doesn't get us anything. Like with any other validator, if it becomes a problem on the post quantum day, if they don't register, we're just going to eject them anyways. it's true that money will be lost, but they that money will be lost anyways, even with this proposal. So I don't see what do we gain by adding complexity now for something that anyways we're gonna be end up end up doing. And we know that we are going to have these validators losing that money because they just lost it their keys. But it might not be possible that they lost the keys. It might just be that they're lazy or they're not following the program. I understand. But and and if they are lazy, they are not going to send the registration and then they're going to lose their money exactly the same way that DCIP gives us. Well, then that also means that those nine thousand validators, thirty to eat each, will lose all of them in one single for transition. Which is, in my opinion, is quite a huge of a change. Whereas if you drain it slowly over time, it'll be less controversial. I think the draining logic is overly complicated. I also commented on on the issue and I also commented here in the chat. I would just suggest that in H Star we're not gonna allow any more zero zero zero deposits. So we basically stop dealing with those and new new deposits and we just need to find a way how we can basically incentivize those remaining nine thousand validators to change their withdrawal credentials to zero zero one. And I think the best way to do that is basically forcing them to exit at H star as well. Okay, so that's like the first EIP that I propose. Yeah, basically the first EIP in with a combination of basically once we hit H star, then those validators will be exited. And at that point, they will still be able to change their withdrawal credential and withdraw all their ETH. or we maybe we can do that at I star so that we would give them some heads up. So like in H star we stop accepting new deposits in iStar we would basically say when we hit iStar we we exit all the validators that are still zero x zero zero. So you would have to basically change your withdrawal credential before the i star hits. I don't even think you need to you need to give them a heads up because if by exiting them, like they're not the funds are not lost at all. They're just not earning rewards and they're just not getting penalties either. So I don't think we need like I don't know six months or to one year of know the same period for them. Okay, I think we should time box the discussion for today as well. please reach out to NC or use ether and d to discuss it further. any other agenda items or topics people want to quickly talk about? Awesome. then on a closing note, based on the vote, the polar bear has been selected as the mascot. so please update your ASCII art. And thank you everyone for coming. see you in the next AC DC.