All Core Devs - Consensus #184

Transcript

Parithosh Jayanthi: Hello.

Pooja Ranjan: Hello. But yeah, I will be supporting with streaming today, so let me know whenever you are ready.

Parithosh Jayanthi: Excellent, thank you.

Potuz: Pooja, can you hear me?

Pooja Ranjan: Yes, potu. All good.

Potuz: Thanks.

Vitalik Buterin: Hello!

Ansgar Dietrichs: Hello, Lolo.

Parithosh Jayanthi: Hey, hey, let's give everyone a few, like, another minute to join, and then we can start it.

Lion Dapplion: a new SEO.

Parithosh Jayanthi: Okay, Pooja, can you start the stream?

Pooja Ranjan: We are live.

Parithosh Jayanthi: Perfect, thank you. 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 7 bugs?

Barnabas Busa: Yes, we currently have, a fork of Prysm running to submit some, Invalid blocks, and Prysm was basically, Unable to sync up to those. I think currently Prysm is on a parallel fork. We have let the team know, but I'm not sure what the latest is from their side. So right now, I think everybody other than Prysm is up to a head.

Parithosh Jayanthi: Okay, awesome. And I think, Lodestar as well, so Lodestar and Teku have been trying out some tests, as far as I know, there's a PTC fix pending on Lighthouse. Okay. If that's the case, then the next open point on the agenda was the Beacon API PR, number 630. 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 have it in the spec for devnet.

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. Bosul wanted to bring up sparse BlockPool and revisit the discussion. Bosul, do you have the floor?

Bosul Mun: Hi! So at the last ACDT, we discussed making the EIP-8070 engine APIs purchase updated V4 on Capital C4. 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 any CL client teams have any thoughts or… concerns about this, I would appreciate it.

Parithosh Jayanthi: Do any CL Devs want to speak up? Okay, I guess we can discuss this in the interrupt chat on ETH R&D. Is that fine for you, Bosul?

Bosul Mun: Yes, for, for the question of whether NCL clients have implemented this, Currently, Prysm and Lighthouse, I guess, 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 objections, 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. Something like that.

Parithosh Jayanthi: 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… ACDT on Monday. If no one speaks up by then, then we should just add it to devnet.

Bosul Mun: Thank you.

Parithosh Jayanthi: As a quick note, is someone from, Prysm 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 DevNet8. Okay, I guess the discussion would happen on the interrupt chat, if anything, but yes, otherwise, it's already in the specification, and we should be to go. We have a specification ready for devnet 8. Barnabas, do you want to give us an update on when we want to launch it?

Barnabas Busa: 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 DevNet8, 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.

Parithosh Jayanthi: Okay, that sounds good. And just for general knowledge, what's the spec going to look like for DevNet 8? Is it the public devnet? What's the plan? How can operators onboard themselves, and so on?

Barnabas Busa: Yeah, so I just linked the, current spec sheet, and this is going to be a named 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 named testnet that could 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 onboarded. 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 There was for approximately a week after, Genesis.

Parithosh Jayanthi: Great. And if anyone wants to be Genesis validators, for example, large staking providers, etc, who should they reach out to?

Barnabas Busa: 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're gonna have Dora off for the deposit option. To submit your deposits.

Parithosh Jayanthi: 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 is 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 PFI 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 DevNet, 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 EIP8359, Beacon Block Reporting Feed. Hannabu, do you… are you around to discuss it?

hanniabu: Hey, can you hear me?

Parithosh Jayanthi: Yes, go ahead.

hanniabu: Cool, cool. So I'm proposing EIP8359, 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 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 order marks.

And there's no insight into multi-node setups, such as dbt, Vero vouch, things like that. So, this EIP introduces a 32-byte field in the BeaconBlockBody. 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, Bouch, Obol, things like that. And, it… supports a M of N threshold up to 6 at the moment. And 14 client pairs. With up to 13 CL client options and 13 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 to that?

Luca | Vero: Maybe just that it's, yeah, like you said, it's slow in terms of complexity. I created some reference implementations. You can take a look at those here, just so you have an idea what it looks like.

hanniabu: I'm not familiar with the format. Is there usually, like, a little Q&A session? I don't know how that works.

Parithosh Jayanthi: Exactly. So we've timeboxed this for about 5 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 feel that we have today?

hanniabu: So, I mean, you're working with limited space. So that in itself is limiting already. And even with the condensed, information that it currently puts in, which is Just the current client. most of it is… for a lot of clients, I guess up to 40%, since only 60% are reporting. That watermark is overridden or pushed out by the, the client's graffiti, the user graffiti. And again, you would need a lot more space to show multiple clients, and the setup types, things of that source. Yeah.

Parithosh Jayanthi: Yeah, makes sense. Does anyone else have questions for hanniabu?

hanniabu: Not all at once.

Parithosh Jayanthi: Okay, great. So then we, yeah, we can discuss this on the ETH R&D server, I'm assuming there's also an ETH Magician's post, and yeah, we can… yeah.

hanniabu: Alright, thank you.

Parithosh Jayanthi: Yeah, thank you. Next item on the agenda is a quick slots from Barnabé. You have the floor?

Barnabe Monnot: Hey, everyone. Let me share my screen. Can you see the slideshow, Pari?

Parithosh Jayanthi: Yes, looks good.

Barnabe Monnot: Okay, super now. Alright, so, faster ethereum, a quick case for quick slots in Hegota. and Barnabe from EF. As a larger point, I would say that faster ethereum is something we care about quite a lot in EF, and we see Quickslot as kind of a really important prong in making ethereum faster. So why does this matter? Like, we very strongly believe 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 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 takes faster.

You have fresher prices for on-chain markets, as Vero 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 faster slots, so that's really, really nice. And something that's a bit underrated, 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 censorship resistance, and in particular, the economic censorship resistance, so how much it costs 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 lower Ethereum… lower latency ethereum is just more value to the network in general, and this value also does accrue to ETH, the asset. So here's, like, the quick, one-two 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 supports the chain. And then second step, Once we have removed this assumption. proceed with a moderate decrease. And here, we are targeting 10 seconds, so that would be 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 community that I polled, 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 slot 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 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 I think 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 do, like, this one-time cost of removing, like, the 12-second hard-coded assumption in the fork after Hegota, which is H-Star. It's expected that decoupled Consensus will be Or at least is currently, like, the frontrunner for that fork, and this is, like, a huge piece of work for the Consensus layer, and from informal discussions with the teams working on this, like, it's not believed that coupling this with a slot time reduction would be… would be safe, unless the work of, Reducing that, removing that assumption was done beforehand. And so, doing quick slots in H-Star means that we open the door to more gradually, like, decreasing the slot time, perhaps in I-Star, with decoupled Consensus, that gives us a little bit of headroom, and maybe again in JSTAR.

So, yeah, we can just have value delivered continuously instead of no value for a long period of time. So here are a couple of considerations. So I polled the client teams, particularly the consensus-layer client teams, EF protocol teams, other people in the ecosystem. This is sort of the main technical blockers that surfaced. Through these discussions. I'll go through them one by one, but with some thoughts on where we're at with fixing or removing these blockers. The first one is, slot zero. There's a little bit more business logic happening on the Consensus layer 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 working on optimizations already.

There's, of course, the attestation and abbreviation latency, so that's one of the key bottlenecks. This is 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 slot time? Because right now, the data is priced constantly with how much time there is for propagation versus execution. My understanding is that it's fine either with, like, if we need to reprice, that's something we can do, and we've already set up, like, most of the testing infrastructure to figure that out. But we can also probably scale the slot time in a way that we don't need 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're actually doing, like, a survey with Sourceify team on identifying this contract, and we already have, like, some of the largest contracts that might have this dependency identified, so 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 Etherscan, they said, for them it's more load, but 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 can do that, I mean, it's doable, and if we do decide to do it.

compatibility with Decoupled Consensus. Actually, Decoupled Consensus, in my sense, was built… one of the design objectives was to move finality out of a 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 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 far from the efficient frontier for that trade-off at the moment.

And finally, I think post-quantum is probably one thing that's 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 work at the EF, are that 10 seconds in Hegota would be perfectly fine. Yeah, so that's it. I think that's already quite a lot, but if I missed anything, of course, like, you should reach out 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 these technical blockers, and I left a few references here, and in particular, we got started on specifications for Consensus layer and execution layer.

Thank you.

Parithosh Jayanthi: So, thanks. I think we have a few, questions in the chat. We have, like, 7 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 jump. Is it true that both the main issue is variable, slot times at all, but also all the infrastructure assumptions have to be re-evaluated separately for each decrease? Dustin, do you have to want to add something to this, or is this ready for Barnabe to answer?

Dustin Brody: No, I think that's ready for Barnabee to answer.

Barnabe Monnot: Yeah, yeah, thank you for your question. I think this is… sort of what I was trying to convey with My opinion is that… we are most likely never going to do a one-time big jump of the slot time and then call that done. I think we always want to be… quite conservative and careful 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 folks or anything, like, we can still peg changes to… to HartFox. 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 client implementation, so… So yeah, I… I do think, like, last year when we discussed Amsterdam, I think there was a lot of, push back on moving from 12 to 6 seconds. I don't see that improving 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 then work on making future changes as painless as possible, and I think this is totally, totally doable.

Dustin Brody: Well, I wonder about that a little bit, because, like, I mean, Lion here mentioned, and I agree with this personally, you know, or a skepticism about it, is 12 to 10 worth it? So, like, I… because you're… you're eating a lot of the disruption, and the structural disruption, and cost for, honestly, not… It's not that much better.

Barnabe Monnot: Right, I think we… I agree. I mean, obviously, I was, again, pushing for 6 seconds last year, and I think this is still, like, a target in my mind. I'm just no longer confident that we can do this much at one go, and so I think we should… Agree, and this seems to be, like, a fairly widely agreed upon stance, that pastor slots are valuable and important. And right now, I think the best way to get there, maybe ever, 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 10 is better than 12, and then possibly 8 in I-Star is better than still 12 in I-Star, and then maybe even lower in JSTAR is better than still 12 in JSTAR, so I…

I… looking at the timelines, I feel much more confident going forward with a moderate decrease. Even that decrease, to me, has value already. Like, 12 to 10 is… it's not insignificant, it's not 12 to 6. But it is, it is something. It is something that… that can be, yeah, that can deliver value to the network. Like, for instance, the fast conversion rule has… gets actually a bit slower with EPBS. Moving from 12 to 10, like, we are dampening a little bit of that effect of EPBS, delaying some of these timeline, so I… these are just fixes in a way, but… but beyond that, I think we… we also have other places where the value actually gets delivered.

Parithosh Jayanthi: There's one more question from Justin about gas limits and blob limits. Do we scale them, or how does this work?

Barnabe Monnot: Yeah, I think in the… in the specs, we have kept the throughput constant, so the gas limit and the block 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, this 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 Invariance are kept invariant, and if we do want to change the gas limit, we need to make an active decision for it. Like, this is not a backdoor gas limit increase.

Parithosh Jayanthi: 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 times?

Barnabe Monnot: Yeah, I think quite a bit of effort, like, we're scanning basically the entire sourceified database of verified contracts, but we already identified, like, a few big contracts where this parameter shows up, so off the 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… A bit of room to… some time 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 dispute resolution game in the bold. And these are two big contracts. I could pull the survey that we did. I think some of your other big contracts were…

eigenLayer and possibly other, staking-related contracts, but I think… From a very initial look, most of the parameters are governance, are still governed by some kind of governance, yeah. Oh, I see, yeah, Dima… Dima?

Dima Gusakov: Yeah, yeah, yeah. Just a quick jump from my side. So, like, even though 12 seconds is now hard-coded in light of 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 12-second assumption on-chain, which means that we will just need to do one upgrade, and after that, like, if you guys would prefer to reduce load time further, there will be no action required from Lido. So we are pretty supportive for the proposal.

Parithosh Jayanthi: So, thank you. Any closing… sorry, yeah, go ahead.

Lumi | Offchain Labs: For Arbitrum, we've looked into already the changing the duration, and then we have a second plan also that is more complex. That we might want to implement instead, but it's not a blocker.

Parithosh Jayanthi: Awesome. Thank you. Any closing remarks, Barnabé, before we move on to the next topic?

Barnabe Monnot: No, other than, let's do it. I think this is really important, and again, I do think this has a lot of support from the community, so… Yeah, we should really just get started and… and… and look towards H-Star Referral.

Parithosh Jayanthi: 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, WAP's profile for FOCIL eligibility. Tama, please, you have the floor, please go ahead, you have about 5 minutes.

soispoke: 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 FOCIL inclusion guarantees. Right now it's pretty, you know, straightforward to establish how FOCIL works with just, like, regular transactions. It basically just, like, checks nonce and balance, and… It's also… it's also working fine with, transactions from, like, 7702, Delegated accounts, but… if Prime Transaction 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 FOCIL, and will always benefit from it, even in, like, a post-DK VM future, in which, you know, you have some nodes that might only hold, sort of, partial states, like VAPs, and which, you know.

frame transactions fall outside of FOCIL enforcement because, I don't know, they touch arbitrary state during… in the verify frame, for example, 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 contracts so that they know the transactions coming out of them will always be eligible for FOCIL 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's, and it's, yeah, again, informational.

Parithosh Jayanthi: Awesome, thank you. Are there any questions for soispoke? Okay, thank you. Next item on the agenda is, EIP8142, blob columns propagation. Do we have Kamil on the call?

Kamil Salakhiev: Yes, everyone.

Parithosh Jayanthi: Please go ahead.

Kamil Salakhiev: Yeah, give me a sec.

Parithosh Jayanthi: Yeah, we've allocated roughly 5 minutes.

Kamil Salakhiev: Okay, yeah, can you see my screen?

Parithosh Jayanthi: Yes, please go ahead.

Kamil Salakhiev: Okay, great. So, yeah, this is Kamil from EF networking team. Yeah, we'd like to PFI blocks in blobs. Yeah, the high-level idea is we're putting execution payloads into blobs, and then we… You're leveraging existing PeerDAS 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'll consider this to be… Quick win, because we reuse existing PeerDAS 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 ZKester's future, which would not require… would not require the full payload, after 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 fetched 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, but we only advertise that we request the bits, well, the rows that correspond to execution payloads. And, yeah, this is kind of nice, because that way we're already kind of using existing PeerDAS columns that we have. Yeah, we can leverage them to take advantage of error coding to propagate payloads faster.

And this also gives us, Flexibility, because, for example, well, the execution payload Rose, 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 bid is accepted. However. This is not the case for the balls, and balls can't 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 attest, 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 Skip subscription to… all columns, and can I use this low-level deltas mechanism to Can reconstruct the full payload if they want? Or 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 gossip's app. compared with the strategies that I described, where we use, basically, columns. for that, and yeah, we also used, yeah, reference EP2PC broadcast propagation, for comparison, and

Parithosh Jayanthi: Kamil. Could you, wrap up in the next minute so that we still have a few minutes for questions?

Kamil Salakhiev: 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 Magicians, or yeah, check the EIP. Thanks.

Parithosh Jayanthi: Thank you. Yeah, potuz, go ahead.

Potuz: 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 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 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 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, today is set at 6 seconds, and the blob deadline is at 9 seconds. I don't see how the PTC will be able to carry this if they are coming together.

Kamil Salakhiev: Yeah, for the… first part, I guess, like, yeah, we can. Well, we cannot yet indeed prepropagate execution payload blobs yet before the bit is kind of accepted. Which is not the case for both, as I described. I didn't really get the second part, what do you mean?

Potuz: Well, the PTC needs to get all the blobs. That they are needed custody before today, 9 seconds. But they need to get all of the payload before 6 seconds. So there's… if the payload is propagating together with blobs, then they just will… this will force blobs to be before 6 seconds for the PTC to be attesting.

Kamil Salakhiev: 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.

Parithosh Jayanthi: Terence, but could you be quick?

Terence Tsao: 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 roofts, but then there's 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.

Kamil Salakhiev: Yeah, right. Eip addresses that, I guess this also kind of will be introduced in phases. Yeah, there were ideas, like, maybe… Just… well, every… anything that's related to pricing maybe comes next, and maybe not in the H star, maybe later. That's still TBD. Yeah, we will raise it. I guess maybe in the upcoming P2P calls, or… Yeah, so…

Parithosh Jayanthi: Thank you. I guess people can reach out to you on the peer-to-peer call or on ETH R&D, right?

Kamil Salakhiev: Yes.

Parithosh Jayanthi: Great. Thank you so much. Next item on the agenda is RowDAS. Do we have Csaba on the call?

Csaba Kiraly: Yes, I'm here.

Parithosh Jayanthi: Yeah, please go ahead, you also have roughly 5 minutes.

Csaba Kiraly: no slides, so I'll be just talking. Yeah, so it's EIP-8371 RowDAS, Distributed Blob Reconstruction. So what we target here is, is a weak point of, of PeerDAS, which is how the construction is done in SuperNotes, and, in SuperNotes only. The construction is CPU intensive, and it also scales in other VWAP count, two properties which are just not nice. And then there's the other… thing that the construction requires super nodes. We do have super nodes, but it's still not nice to rely on the fact that we need super nodes for this robustness. So the proposal is to… Find a way to distribute the deconstruction, the construction. And we would do that with, low… low topics, and use on cellular messaging and that, so partial messages.

What we would do is, allocate those 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 allocation. And also this allocated job would be rotated, to balance the load. So, that would be a mapping permutation from job IDs to the IDs, in each slot, and, that would decide what goes where. The… Yeah, elements of this were coming from Full DAS from, from the P2P extension for password messages, that we're using for the, On the comms. And, yeah, the overall effect would be that,

SuperNotes, would be able to focus on, on a single, Hello? Do the reconstruction for that. So we would divide, kind of, the deconstruction phase for superplanets into two phases. A first phase, when they are just focusing on their allocated low, everyone on their own allocated low, and they would share this. And then a second phase, which would be basically What's happening now, which is, again, Reliability mechanism, behind the distribution. So that, first advantage would be that, so that, super nodes would, would do much less work in, Typical conditions, which is they would just deconstruct one, one, though, and you can say super nodes, could have many cores, 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-super notes. So non-super notes could also chip in into the construction. They would collect, notifications on these little topics, so the… yeah, maybe an important part that I didn't mention is that, these low columns are… we are not pushing messages on these. These are just, notification-based, so Bitmap exchange, so they could collect, on, on these, allocated those, and participate in the construction. Again, this would be more or less a voluntary or as a delayed mechanism in case super nodes are failing for one reason or another. What this is not, this is not full DAS, so this is not, subdinal cellular sampling, the sampling is not changing, it's still coronal sampling, is the same.

There's also no compromised encoding, like in FUDA, so we are not changing, kind of, the column structure. This is, boilted on top, relatively small change. And… aims to… to use the CIP load to make the system more robust. There is also a related thing, which is typical EL2 nodes looking for specific blobs. This is not helping them directly, it helps… it's… helping them indirectly if they are a supernode, because they have less CPU load. And I was leaving in a pod, discussing this in the IP. We can also… but 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.

Parithosh Jayanthi: Thank you. Any quick questions? Great. Then please reach out to Csaba if you have comments, or, yeah, use the EIP to discuss. Thanks, Shiloh. Next item on the agenda is tapered issuance bond. Do we have Jerome on the call?

Jérôme de Tychey: Yes, can you hear me well?

Parithosh Jayanthi: Yes, please go ahead.

Jérôme de Tychey: Awesome.

Parithosh Jayanthi: You have roughly 30 minutes.

Jérôme de Tychey: Wow, that's a… that's a lot. I just requested, 3 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. Oh yeah, it is. Okay. Alright. Good morning and good day, everyone. I have dropped a link to those slides in the chat. I'm here to present you EIP 8363, called Tapered Issuance Burn. There's a link to the EIP in the slides, and there's also a link to the EF Magician Tread, if you want to discuss this in, in further detail. So, as a quick overview, this proposal primary goal here is to remove the issuance mechanism's incentive for stake growth. once the staking ratio exceeds 50%. It accomplished this by deducting a burning… deducting and burning a tapered fraction of idolized Validator rewards at each epoch boundary.

So that the net staking yield declines linearly, while the staking ratio, with the staking ratio, enrichs 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 are 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 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%, meaning the incentive to stake, 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 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 has security and centralization risks, notably that high staking ratios, degrades Ethereum securities by concentrating stake. It's also creating more 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 EF being held at custodians and staking services, the social layer, the EF 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 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 EF as the working money of the ecosystem, which introduces counterparty smart contracts, and governance risk. So why are we proposing this for inclusion on H-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 H-star. The window closes on its own, and the reform gets harder every month, because we have more and more EF at stake.

The proposed solution is the following. We are introducing a tap-and-burn function that has a 50% saturation point. This allows for a market-driven equilibrium regarding the EF 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 Prysm 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 months 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 HSTAR, they will likely be about 2 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 EF 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 getting, because For now, we perceive that there's a lot of, misconception 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 informed opinions, 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 shows key figures you can also peruse to sum up the thing. And, yeah, that's it for me. I've only prepared for 3 to 5 minutes.

Parithosh Jayanthi: 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?

Barnabas Busa: 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 where it is right now, but just, basically limit the, issuance in case that we do achieve more than 50%.

Jérôme de Tychey: I'm not sure I get what you mean by that. You are… are you suggesting that we limit the inbound of new validators? Did I get your comment correct?

Barnabas Busa: Yeah, something like that. I'm not sure technically how we would do that, but I'm sure that we could think of a way to do that. So you can basically only deposit the new Validator. In case we reach 50% of the staked ETH, the only time we would, Basically, the deposit would reach the Beacon chain contract is if someone exited.

Jérôme de Tychey: So that's, that's indeed, a possibility to, actually cap the 50% EF at stake, but this has also consequences 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. Then the tapered issue ends during our discussion. And it also opens up on a different form 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 an interesting comment, I'm happy to, to give you a deeper analysis in DMs as well.

Barnabas Busa: Yeah, my main question would be, what is the actual goal here, of 8363? Is it the partitions, or is it the 50%, or is it both?

Jérôme de Tychey: So it's… to limit the stake ratio grows at the 50% state. That's the primary goal, that we are looking for here.

Parithosh Jayanthi: Thank you. The next person's Oisin, please go ahead.

Oisín Kyne: 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 staking ratios or not, but, like. Firstly, Jerome, do you think that this proposal will make a 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?

Jérôme de Tychey: 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, that are different versions of the Nakamoto, notably how easy it is to challenge it and grow it or lower it, depending on the accessibility of the network itself. I, I know this, coefficient is very, dire to you, and you are oftentimes 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 is, and what it will become, depending on the different implementation of a proposal that we consider.

Now, when it comes to the diversity of the Validator set itself, it's a… 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 generally undecided, like, who goes out first and for which reasons. They are, interesting, points to, to look at, nevertheless. we have good consideration regarding the solo stickers. From our point of view, an issue and change should, by all means, protect the solo stickers, 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, service providers, which introduces a new risk for them, which is, the sticking 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 staking service providers. In which case, we are in the… based… best of both worlds. We have reduced these ones, capped, the 50% ratio, of EF at stake, and also preserved the… the…

Sort of stickers. Analyzing the reservation yield is an ongoing process. We are taking feedback from the community 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 dilution low. So, the framing that we use is that we consider 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 dilution adjusted.

In which case, the tapered is the one that perceived the highest result, net result, for the longer time for the solo stakers. Sorry for the long answer.

Oisín Kyne: 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 org are, 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 heat, 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, from both sides, looking at kind of 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 main blocker here. And I think we're over-indexing on, what, somewhere between 2% and, like, 0.2% of the network, whereas, I don't know, the vast majority of the network 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.

Parithosh Jayanthi: Thank you. Greg, I think…

Greg K | Lido: Yeah, so, yeah, I wanted to mention that I would, kindly, request from authors to withdraw this, peer fine for Hegota, because I think this EP 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 Hegota, 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 ACDC in, April, there were some discussions in Cannes, and, it was really no… not particular CF discussed, like, we have very generic discussions around these ones. So I think this doesn't give time for people, like, to prepare better and already give counter-proposals about these ones, since the…

common expectation was that these ones will be discussed for later forks. So now, having one EIP for each one's for HEPA, this, will create this kind of confusion, like, it will be the only option, so it will appear, like, either this EIP or noise transce at all, and that could have, like, I think, not-so-good, like, not-so-objective, like, Give not objective image of what's going on. And yeah, it seems that, like, happened only, like, this EIP appearing now. It's too late to… start having, you know, constructive discussions. Seems like, for Hegota, we already have, like, 40 EIPs proposed. a lot of them have very useful features for Ethereum. We have spent so much time working on them, like, everyone, and having, like, Ethereum discussed and dominating, like, the next one or two months for Jakota, I think will really, kind of under, like, feel under the other many useful things that people are working for a long time. For example, like.

We offer two EIPs for Hegota, we prepared them, like, since the beginning of the year. So, yeah, I think that having now a new EIP for such a topic, such controversial topic, to kind of get the whole discussion on it, it would 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 EIP, like, where everyone agrees or not. But, yeah, not having it as proposed for inclusion for Yukota. Yeah, and, yeah, on the specifics of the EIP, 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 goal response 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 EIP, but, requesting to withdraw the proposal for inclusion for Hegota, and then we'll have enough time to, you know, interact and have constructive discussions on it.

Jérôme de Tychey: Well, first off, Greg, thank you very much for sharing your concerns regarding the time left between Propos for Inclusion and Consideration for inclusion and so on. Yeah. So, the curve that, we presented was, more, previously, shared at, different workshop groups, I think notably in Cambridge by Apache. I have to, I have to check this out. But, indeed, we got, we got, taken by the time, and, we had, we, we got, we had a, we got a… we have to act while the… we thought in introducing this PFI that we have to act before the situation becomes too dull and too complex to fix. Because once it's too complex to fix, and too expensive to fix, the cost of doing it may just be something that we completely put on the side.

In the publication of the… the strawmap roadmap in, later 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 EF was, going at stake? The, the arithmetics is, advocating, in our view, against, delaying this change. Now I've well noted your request for us to withdraw this, and we will, think about it. But, yeah, we have to consider that 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 50% of EF at stake, with all the consequences regarding security and money nas for EF.

Or, if we are going to start, having, an intense discussion now, we are welcoming, the feedback, and I know many people have posted in the information thread, which is really great, so that people can start to make a more informed opinion, and also, help us 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 window for having those discussions. And the fact that we are having it now is very positive, I think, because it makes people realize that, Do a problem actually exist?

Greg K | Lido: Yeah, but the point is that this EIP is not only addressing the high-stake ratio issue, so if the only thing that this EIP 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 2 years, 33 years, we can reach this point, and because this is a problem, I have a way to fix it. That would be the case, but this EIP is doing much more than just this, because it completely redesigns the HRMS curve. It redesigns the HRMS curve, but 10% is staked, 20% is staked, 30% is staked. And this is completely not necessarily about, like, the future staking ratios.

So, if you had an EIP 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, to have an EIP that from now, like, proactively set something for the future that does not allow something to happen, but this is not the case here. So here, we have an EIP with a full Ethereum redesign, and this is presented just two days before the end of the window, while no one was expecting, actually, that these funds will be considered for Hegota. So this, I think, is very, very, I don't know, a bold move. So, yeah, it would be great if we could just, you know.

We can have discussions about the EIP, but not, proposing for Hegota.

Jérôme de Tychey: One quick comment, regarding, the main objective of, keeping, via the EF reference curve, the amount of EF at stake at 50%. We will gladly produce, analysis of, the previous, request, the previous comments on the… from Barnabas regarding why not do, just, end-of-the-entry queue after 50%. And why we, we prefer to do it via the issuance curve. One needle 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 0% of EF at stake beyond 50% right away, but the transition is much longer, and thus less impacting, the yield curve provision.

before the 50%, of course. So there's a different way we can approach that, and we are glad to get so many feedbacks and concerns being raised, because it helps us shape the design.

Parithosh Jayanthi: There were a couple of, comments, potuz, do you want to maybe speak up about your comment?

Jérôme de Tychey: I'd like to add that I will, personally commit to answering all the comments on, the EF magazis and Fred. It's taking some time, obviously, but if you have any things you want deeply addressed, drop it, and, expect me to deal with it.

Parithosh Jayanthi: 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 EIP. The decision is not being… Taken away from you that way. And the PFI decision is, 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?

Dima Gusakov: 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 thing as community response into account, because in most case scenarios, the response from the community is a good way to understand what's gonna happen if we do not listen to them.

Jérôme de Tychey: Yeah, that's a very pragmatic and important observations. Nevertheless, 48 hours of barrage fires and outrage on algorithms that favors 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 an informed opinion on the matter, and not jump into a conclusion too fast. I'm… a community member. I'm a solo sticker 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, ethereumStake 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 strawmap roadmap as well. So, I get that many of you that expressed their opinion vocally here are against even considering that for H-Star, but the debate is also positive, and it will help us all together converge to what's good, what's the best for the greater good of Ethereum itself.

Parithosh Jayanthi: Thank you. Ansgar, you had your hand up, do you want to say something?

Ansgar Dietrichs: Yeah, I mean, I'm not sure, I just 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 the increasing stake rate, and do, in principle think that, a change like this makes sense. And nevertheless, I don't… I think 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 AllCoreDevs, but in my opinion, that is not a risk. I think, to me, it is clear that a prerequisite of a potential acceptance down the road would be that in the process of that conversation, kind of, like, the overall perception would shift, and people would be more open to this change. I think… Yeah, so I just wanted to basically say this, because I think it is otherwise, of course, very corrosive for Ethereum if there is a perception or even just a concern that potentially a divisive change could be pushed through against a majority community opinion. So even as someone personally, very,

concerned about the topic and open to a tinge like this, I still wanted to stress that.

Jérôme de Tychey: Yeah, and I want to reiterate my, previous, comments, that I, Totally agree with you on the matter. And I lived long enough in the ecosystem to have seen the Dow Haug, and how the coin vote and the hash vote happened. There are many ways of, properly, gauging what the interest of the community is regarding this change. And, there's, by no means, no mean, 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.

Parithosh Jayanthi: Great. I'd like to timebox 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 ET&D, there's an Each Magicians thread, there's multiple places to be involved in the topic. Please do get involved. Next item on the agenda is, from Oisin. We have anti-correlation attestation penalties. I think he had an update to present to the existing EIP.

Oisín Kyne: Yep, gimme 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 the 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 on 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 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 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, 2 or 3 months of rewards. In practice, though, that's an extremely large outage, and not really likely to happen. M… So, I'll talk about that in a 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 attesters 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 incorrect head vote.

M… looking back at the chain outage, I picked 3 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. Besu had a halt, Nethermind had an issue, and Prysm had an issue. If you look at, like, kind of 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 it 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 2 or 3 days for it. And then the question they 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 going to 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 24. 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 EIP that would have the community be more supportive 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.

Parithosh Jayanthi: Thank you. Yeah, terence?

Terence Tsao: Yeah, I'll be quick, just almost all the time. How does this work when there's negativity leak? 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?

Oisín Kyne: It's a good question. This has a cap, which is designed to kick in at exactly 33% offline, so it… it is cumulative, like, it's on top of the inactivity leak, but it's much smaller than the inactivity leak. The inactivity leak is pretty severe. I think you can see it here on this slide, if you get to the kind of, inactivity, that's much more the contributing factor. But yeah, this stops after 33%.

Terence Tsao: Thank you.

Parithosh Jayanthi: Awesome, thank you. We have, 3 more, 4 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?

NC: I'm gonna share my screen. Can you see my screen?

Parithosh Jayanthi: Yes, please go ahead.

NC: 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 0 validators are pretty old, and, maybe just, like, a quick, recap. Oh, on, what this does. So, basically, it has a sign-in key and a, withdrawal key, both of BLS, and the sign-in 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 0.01 validator.

And a, property of 0x00 Validator is that it doesn't have an 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 an address to withdraw to. It can, do the regular, their duties. But, there's no way to withdraw funds. And, The protocol can eject the Validator. But, after that Validator is exited, the fund still remains on CL side. So, it's a really weird interaction this way. So, just some, high-level stats today in the… on mainnet. There's still around 9,000, but they still hold the 000 credentials. And, less than 9,000 if, you just exclude the ones that are offline for more than 6 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 0x00 values being created. So, 0x00 doesn't cause a lot of, problem today. It's just, like, some minor, troubles. So, for example, like, protocol cannot, remove a 0x00 validator. There's no way to, withdraw that fund to anywhere. And also the clan teams, needs to maintain, like, the BLS execution change mechanism, like, all the gossip stuff, and the upwall, 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 ignorant, 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 Validator duties, but they cannot submit the BLS to execution change to become a 0x01 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, Vale Registry. proposals. Every single one of them requires, every Validator to perform a certain action. Maybe it's 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 ETH swept to the EL side, 0x00 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 0x00 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 To convert the, validator and fast to, withdraw those funds. Or, we just delete them from the registry, which is a very, a brute force way to dealing with them, because it's basically, like, confiscating the funds, just, like, drop their balance from 32 ETH to 0 ETH.

And alternatively, I've also thought about, like, maybe you 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. Also, you are basically, continue to maintain this Capella tech debt and convert into a PQ tech debt. I think PQ is a excellent opportunity to get rid of this, but if we go the other way, then we just continue to maintain this. And the maximum usage of this PQ version of the elasticity change is just that 9,000 validators, which, 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, 0x00 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 executing change. It's pretty straightforward. And then the second step is to drain, so that, the balance, will decrease over time, slowly. So that, The goal is to get all of them to have a balance of zero by the time we transition to PQ, so that we don't have this, like, cliff, that drops, 32 ETH to 0 ETH, like, at one for transition, but, like…

Parithosh Jayanthi: 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 know.

NC: This is, like, my last slide. Yeah, so basically just train 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 EPIP transition 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 do… how to deal with 0x00 validators when PQ comes. That's it.

Parithosh Jayanthi: Awesome, thank you. I saw a bunch of messages from potuz, Barnabas, came in. Do one of you want to speak up, or Dustin? Yeah, go ahead, potuz.

Potuz: I didn't understand that what do we gain from this? So, I do get the point that perhaps we want to deprecate 000, and that's an easy change, which is don't accept any more deposits after a while, that's a clear indication that you shouldn't be depositing validators with a zero BLS credential, but like, the exit, the forced exit, 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 doing.

And we know.

NC: No worries.

Potuz: We are going to have these validators losing that money because they just lost their keys.

NC: But it might not be possible that they lost their keys. It might just be that they're lazy, or they're not following the program.

Potuz: I understand, but… and if they are lazy, they are not going to send a registration, and they're going to lose their money exactly the same way that this EIP gives us.

NC: Well, then that also means that those 9,000 validators, 32 EF each, will lose all of them in one single fork 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.

Barnabas Busa: I think the draining logic is overly complicated. I also commented 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 000 deposits. So we basically stopped dealing with those new deposits, and we just need to find a way how we can basically incentivize those remaining 9,000 validators to change their withdrawal credentials to 0x01. And I think the best way to do that is basically forcing them to exit. at H-star, as well.

NC: Okay, so that's, like, the first EIP that I propose.

Barnabas Busa: 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 maybe we can do that at I-Star, so that we would give them some heads up. So, like, in H-Star, we stopped accepting new deposits. In I-Star, we would basically say, when we hit I-Star, we, we exit all the validators that are still 0x00, so you would have to basically change your withdrawal credential before the Isor hit.

NC: 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… their 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, 6 months, or to 1 year of noticing period for them.

Parithosh Jayanthi: Okay, I think we should timebox the discussion for today as well. Please reach out to NC or use, ETR&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 SCII art. and… Thank you, everyone, for coming. See you in the next ACDC.

Marius van der Wijden: Bye-bye!

Jochem Brouwer: Right.

Kevaundray Wedderburn: Right?

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