All Core Devs - Consensus #185

Transcript

Parithosh Jayanthi: Blue.

Pooja Ranjan: Good morning.

Parithosh Jayanthi: We will wait another minute, and then we can start.

Pooja Ranjan: Just let us know whenever. We need to move the stream.

Parithosh Jayanthi: Okay, yeah, could you start the stream, and we can get started?

Akash | ECH: Yeah, VLA.

Parithosh Jayanthi: Awesome, thank you. So, high level, we're gonna talk about, DevNet 8 today, start preparing for testnet, decisions, and then talk about Hegota afterwards, because we didn't get to a couple of EIPs that, were submitted before the… Deadline, so we want to give them a chance to present their EIPs. Yeah, so let's get started. First item on the agenda is, DevNet 8 status. Barnabas or Stefan, do you want to give us an update?

Barnabas Busa: Sure. So, dominate was very stable till this morning. when we activated Gloas just a few hours ago, I think about 6 hours ago, and we just have gained back finalization, just a few minutes ago. the… Major issue was that some clients didn't, or, or Heather… Bad implementation of caching of builder deposits, to process them during the fork transition. So, we saw this with Lighthouse, Prysm, and Teku. They all struggled to process the first slot right after we activated glass, because we had about 16,000 Builder deposits queued up. to be dequeued on the first lot. So the other client actually managed to process it successfully, and so we only had, like, 50% Issues.

Well, Grandine also seemed to have a bug, where they were sending the proposal preferences Before the fork, which triggered a load store bug. Maybe someone from Lodestar can chime in for that?

Nico Flaig: Yeah, so for the Grandine one, I think that one, is confirmed. But, so on the Lodestar side, we processed them, and it broke our event stream. Which triggered, or which caused us to not submit any bits, at least, like, the builder that was connected to Lodestar. And, I think there might be a gossip condition missing where we should check that the proposal preference is not for a precluse proposal slot. And just ignore them.

Parithosh Jayanthi: Great. Is there any other updates or anything we should discuss right now? For those interested, potuz… Wrote down, put us and Nico both wrote down a bunch of rationale for, why the circuit breaker works the way it does. Besides that, I think fixes are slowly being merged in, so… that Largely addresses the problem for now, right? Are there still any other open topics on Decket 8? Okay, and to address, Dima's point, his concern was that Lido wasn't able to properly test how their oracles and tooling passes, part fork. This is true. So, one thing we're going to plan, in the next weeks is a non-finality network, but what we could do is only start non-finality after the,

after the fork. So, maybe, would that work for you guys? Would you be able to deploy Oracle and other tooling on another DevNet?

Dima Gusakov: Yeah, for sure we will. The only question is for how long the DevNet will be live before Glamsterdam. So, we usually need, like, a day or so in the best-case scenario, provided that we… have available Dev resources, we can arrange for that, but we will need at least a day, preferably maybe two days, before the Glamsterdam would be activated, so that we will have enough time to seed some validators and to run all of this stuff and deploy the protocol, for sure.

Parithosh Jayanthi: Okay, yes, we can do that. Optimism also reached out to ask for another location to test before DevNet, so… Yeah, we might be looking at a similar timeline there. Cool, we'll keep you in the loop. We won't, shock announce it or anything. The main downside might just be that this would be a very big network, so there will be a lot of validators. We might have to do Genesis deposit, we might need to include you in the Genesis state, but we can chat about that. Anything else? What do I need at night. Yeah, I mean, the new DevNet would be open, it'll be a regular public DevNet, but yes. We would also like to see a successful fork before we head to test nets.

Anything else DevNet 8 related? Okay.

Barnabas Busa: Good Vega. To give us an update, or… Why did they fail?

Parithosh Jayanthi: Yeah. Do we want to go client by client? Is someone from Prysm or Lighthouse available to start?

Eitan Seri-Levi: Yeah, on Lighthouse's side, we had implemented the… Optimizations for builder deposits before the fork, but we merged that change Like, a few hours before the… the network forked, and we… Had a implementation issue where deposits that came in Before this feature was added to the fork weren't getting cached. So that's what screwed us. And then right now, I noticed that we have some nodes that are still, taking a while to sync, and we had Optimistic Sync disabled, so I just… Enabled it, and hopefully that will speed things up there.

Parithosh Jayanthi: Awesome. Prysm next? Or Teku?

Stefan Bratanov: I can go for Teku.

Parithosh Jayanthi: Yeah, please do.

Stefan Bratanov: Yeah, so basically, we had an issue where… We're still investigating that, but for some reason, one block was taking… Very long time to do the DHX. And in the background, we also have a… Like, a running, thing which checks, basically, if sync has stored. And it detected the truth, like, we were importing a couple of blocks, and it took a very long time, so we abort this batch of blocks, and then it was just… the same DI check took a long time, and we have, like, a queue of this DI check, so… every DHX takes longer and longer, because there's still one in progress, which was aborted earlier, so… Yeah, we're working on a fix now, but essentially, from what I saw, I saw a couple of notes which basically recover after 3-4 hours, so… that's why I asked Barnabas to restart all the tech notes, which hopefully should fix things, but at the same time, we're working on a fix.

Potuz: So I think Terrence is not here, so I'll just mention a few things that he said elsewhere. One is that the cash for the builder deposit, this was something that was taken out of the branch, so it didn't have it. I don't really understand why. It was one of these things that we were measuring whether or not it was worth it. to keep that cache. The idea of having this extra deposit would just avoid this type of caches, and I think that was the reason why it was removed. But anyways, we had the branch, we just pushed it. But also, there was an optimization that, that… even without the cache, it should have taken just one slot to recover, instead of almost an hour. Like, we finished processing these things in over an hour, and Bastin just put out an optimization that just reduced that, even without the cache, to just one slot.

I think the nodes are stable now, and they're working. It also didn't help that, because of the spec changes at the last moment. then branches were being pushed right before the fork, and this was after the deposits already entered in, so that's essentially what affected the lighthouse, and I think also present.

Parithosh Jayanthi: Awesome, thank you. Do we have, Lodestar or Nimbus want to say anything else?

Nico Flaig: So for Lodestar, it was… I didn't see any issue. There was some optimization I pushed yesterday, which, I had not updated all nodes. Some I ran myself, I didn't update. That… that optimization got us down to, like, 500 MS, From, like, 20 seconds, so all the PandaOps nodes had the optimization, so the fork transition for us took, like, half a second, basically.

Dustin Brody: Yeah, I'll, I'll, I'll… Nimbus, similarly… Have, no real issues throughout, and… when I measured the cache, I used, Dustin Traglia's, Sort of scenarios, ketosis. At a larger scale, and it ended up being still that the state transition was sub… was something like a half a second, on the more stress test cases. I would imagine it was not more than that here.

Parithosh Jayanthi: Awesome. Thank you, PK, do you want to speak to what you talked about?

pk910: Yeah, just to the thing that was mentioned, on mainnet, we won't see all the deposits coming in right before the fork. I would expect them in the weeks, or, yeah, months before the fork. So, relying on hot caches inside the processes Shouldn't work that way, I think. Yeah, photos?

Potuz: I don't think we will have months, right? And definitely not… I mean, definitely not months, and I don't think we will have weeks. The timing is such that builders that want to be onboarded at the fork, they need to… relatively closer to the fork deposit. However, what we don't expect is nodes restarting right before the fork, and essentially not all nodes at the same time restarting right before the fork. So, even this thing of, like, that could be considered a bug, the fact that you don't recache on startup, I think even that should never happen, so… Because we don't expect the whole chain to be restarting right before the fork.

Parithosh Jayanthi: Alright, Yann Nico?

Nico Flaig: Yeah, just regarding the deposits on Mainnet, we have a very long deposit due, so you can… I think even 2 months, almost, before the fork happens, you can already do your builder deposits. Maybe PK has better numbers, but yeah, we should not rely on…

Potuz: It's long right now?

Nico Flaig: Yeah, it's like 30… it's like 40,000, right? So, I think… so what Lodestar does is just two epochs before the fork we start preprocessing. So… because you're also right, like, users will, restart their clients quite, like, maybe 2 weeks before the fork, so… I wouldn't rely on that timing, to be honest.

Potuz: Yeah, so that's… that's what we do. We also, like, processed them before, now with this cache, but… and I think it's just kind of use… useless to try to recache on startup, because we don't expect all nodes to be starting right before the fork.

Barnabas Busa: Well, but it wasn't right before the fork. Like, Prysm was restarted maybe 8 hours before the fork. That's not, like, right.

Potuz: No, we didn't… in this branch, we didn't even have the cache. But but the notes that didn't have the recaching is because they just started after the deposits were coming in. The deposits came in, like, 10 hours before the fork, right?

Parithosh Jayanthi: Okay, anything else to add to this discussion? If not, I guess we're gonna take it on ETH R&D? Okay. Next item on the agenda was, when we had the non-finality DevNet, Are there untriage things left on this network that we should wait for, or does it feel like all the fixes, the cache fixes, etc, are what people want for the non-finality network? Do clients have an opinion on that? Like, if we were to have a non-finality network next week, would that be too early? Can we just go client by client? I'm gonna give, let's say, two, options. One is, next week, and the one, next option's the week after.

And yeah, to Barnabas' point, I guess stable cache implementations, as well as, ideally trunk branches would be perfect, so that we're already testing what would go out to the public later next month. Maybe we start with Lighthouse, Prysm. And then go to the other plants. Lighthouse or Prysm. Would you have all of the changes for DevNet 8 implemented in your unstable branches by next week, or the week after?

Eitan Seri-Levi: Yeah, we'll have it by next week.

Parithosh Jayanthi: Prison?

Potuz: We have them.

Parithosh Jayanthi: Okay, Teku? Nimbus, Lodestar?

Stefan Bratanov: Yeah, we're already on master for… Currently, so we should be… we should be good for next week.

Nico Flaig: Yeah, we have it merged, and it was tested on DevNet 8, so right now, I don't think we need to do any further optimizations.

Dustin Brody: Nimbus is already on its, trunk branch, unstable for definite aid.

Parithosh Jayanthi: Awesome. So, let's try and target next week, and if not, yeah, Grandine, what about you guys? Are you on your unstable branch, or not?

Saulius Grigaitis: Not yet. Yeah, we are, we are still on dedicated branch, but, next week, hopefully, we will merge it to the main branch.

Parithosh Jayanthi: Okay, perfect. So, ideally, by next week, everyone's got their trunk branches, and then we have, Yeah, and then the week after, we could have the DevNet. Just… To Chris's point, I think on the non-dev… non-finality DevNet, that's going to be extremely hard. The main reason is because we're going to run roughly a thousand nodes on this network. we just can't run it for a period of one, two weeks before we finish all the testing, purely due to the cost of it. But it sounds like there might be some space for just another DevNet that… It's not non-finality and basically small, that everyone can deploy stuff and we can let it run for a while.

Is there, some specific thing that, That you want to check? Okay, I guess it's just, about the happy path with finality. Okay. I think we'll have to discuss this and come up with a plan. We'll… we'll let you know, what the approach is. Either… We keep a slightly longer non-finality network, but we'd have to check if we can spend that kind of money on it. I don't think in any world it'll be a week, but, yeah, we could probably do a day or a day and a half. If not, we might have to do a smaller network, so everyone gets to test their happy path as well. Okay, does the plan work for everyone? Maybe to potuz's point,

Yeah, but I think the non-finality network is also meant as a way to give us some confidence that we can start scheduling testnets. And start our progress towards MeanNet. So, the longer we just use DevNet branches, the less it's… Code that we intend to ship on mainnet. Okay, please keep an eye on ETH R&D, and then we can, send some timelines and calendar. There was one, API change that, Patches asked if we can get merged in. It's the Glamsterdam changes for the remote signing API. Are there any big blockers, or has any client team got a chance to… Look into this?

Okay, seems like it's still missing stuff, But yeah, would be nice if client teams can… Review and start implementing remote sign-off stuff, too. Awesome. Next item on the agenda was, trying to see if we can start aligning on dates for testnets. I know that the DevNet today didn't necessarily go as expected, but it's still a really nice edge case test. We have a bunch of plans for, other networks we're going to test on as well, and we don't have to decide the date today, but I wanted to at least float an idea of a date that we can start aligning on. The proposal was to potentially do Sepolia first. The main reason is that the really public-facing change that would affect a lot of users on Ethereum today is repricings, and Sepolia is a DAP

focused DevNet, TestNet, so it would actually help a lot of people to test their repricing changes on. The proposal is to do, the fork on 28th of September, so basically over a month from now. At least process-wise, we want to keep plenty of time from choosing the date to actually having the release, so… wanted to at least start aligning on a date. Are there any initial concerns to proposing this date, or… Are clients more or less okay with aligning on this and deciding in, like, 2 weeks? So, basically, at the next ACDC. Okay, if anyone has objections, then…

please bring them on ET R&D, or, next week at ACDE, or the week after ACDC, we'd like to make the decisions. It's also extremely early to choose this, but the proposal was to then have Hoodi, end of October, so that would still give us plenty of time to see how Sepolia pans out. If there's any, changes that we want to make in, we would be able to make changes and then schedule Hoodi for end of October. Also a date we don't really have to decide right now, but I wanted to at least start aligning us on a shipping timeline. And yes, agreed with, Kingy that all of this depends on, like, getting stable dev nets and…

All the Devs being happy with their trunk branches and so on. Okay, are there any comments, Okay, there's a comment from Dima that he would like to have both, dates a bit later, like a week or so, to have more time for the pending Detna testing. Yeah, I can find what the proposed… Epochs might be if it's a week later, but yeah, we don't have to make the decision today. We can still see how DevNets go in the next two weeks. Awesome. There is, of course, one still, open item for Glamsterdam. Jocham, do you want to talk about EIP7610 removal?

Jochem Brouwer: Yes, so on the ACDT of Monday, we talked in the EL record call about EIP 7610. So, this EIP is about… Let me find the title. This EIP is about to revert the creation in case of non-empty storage. This is… yeah, but I don't have to go into details. We decided to remove this from Glamsterdam. This is not a spec change, because this specifies behavior, but… Can impact this never happen? And after many debates, we settled that we don't want to do this, because implementing this thing leads to, well, performance… well, I would not say performance issues, but clients have to implement something which affects the performance of clients, and it's not necessary. So, to, to answer FLCL's question, is it excluded? Yes, but postponed

No, because we have EIP8283, PFI is Wait, so let me find the correct one. Is it this one? Sorry. Yes, we have EIP8253 for PFI via Hegota, and this directly solves this problem, because this ensures that no accounts of the type which EIP7610 targets are into the state tree. So, well, this, that removes that entire concept. So I wanted to signal that, and I also wanted to bring it up here, because we need to formally sign this off here to remove it. But again, this is not a spec change.

Parithosh Jayanthi: Great. Does anyone have any objection to removing the EIP? Okay, then, I've seen that there's already a draft PR, we should be able to approve it and officially remove the EIP from Amsterdam.

Jochem Brouwer: Yes. Sorry, one final thing, because before you approve that PR, because you can approve that because you are one of the officers of the Gemstone Meta EIP, please first, review And if all looks fine, approve this PR, which I just, opposed, because this moves the, status of the Glamsterdam EIP from draft to review. And it needs an offer of the EIP sign-off, but we need that approval, so please check the EIP, and if all looks fine, please approve it, because then we can move this EIP to review. Thank you.

Parithosh Jayanthi: Okay, perfect. Thank you so much. Do we have any other Glamsterdam topics for today? Okay. Then let's move on to Hegota. We have a couple of proposals that we didn't get to at the last call. So the first one is EIP-8333 from WeMeetAgain. Do you want to talk about align checkpoint with epoch boundary block?

cayman: Yeah, sure.

Parithosh Jayanthi: Yeah, go ahead, cayman.

cayman: Okay, I posted a little slide in the chat, but I'll keep it brief. So basically this EIP moves the checkpoint route The calculation for the checkpoint route to the boundary block leading up to the checkpoint epoch, instead of the First block of the epoch. This fixes, like, a long-standing off-by-one error. in the checkpoint calculation. So if you think about, like, what is finalizing, or what… which epoch is finalizing in the protocol, it actually currently means we're finalizing only the first block of the epoch, just based on… How we currently do things, it's… it's a little… it's a little confusing, and There's a practical benefit to the CIP. It can help improve the target vote accuracy.

So, this suffers on the first slot of an epoch, because when a late block arrives. Not only does the… is the head Vote impacted, the target vote is also impacted. So I think this EIP might pair nicely with the quicker slots, since it relaxes the timing for target voting. That's it.

Parithosh Jayanthi: Awesome. Thank you. Are there any questions or comments? Okay. Thank you very much, Yeah, if there's no comments, then we can move on to the next EIP. The next one being proposed is, Engine API sync status from TerSec.

Dustin Brody: Hi, yeah, yeah. So, I have, I have a… slide, A… slide that I can hopefully, Put up here, We'll see, but, but, like, I'll, I'll, I'll, I'll put it somewhere otherwise, if not. But in any case… Oh, I can share, window… Yeah, okay, sorry, I'm sorry, I'm… Hopefully people see this. I don't know, it's a… Resolution?

Parithosh Jayanthi: It's… it's a bit smaller… yeah, okay, this is perfect. Thank you.

Dustin Brody: Okay, great, yeah. Great. Alright. So… This addresses a bit of a… So this has a couple of broad purposes, and one of them is that, sort of, in the mean… it both fixes some… some issue where, for example, on unstable, networks, and obviously we've just seen an example of that today, but also, especially more highly forked networks. So today, we didn't see that as much. It was not finalizing, but it was not very forked. But on Hoeshky, on some other highly fork networks, for the network to recover, both the CL and EL have to find peers on their fork. So, this has proven problematic with many forks, because you only need one of those to fail, and then neither can fully recover.

for example. The other aspect is that it also… more, sort of, constructively, it means that there's only one sort of gossip of… there's only one sort of block gossip, for example. Right now, it's duplicative. and redundant. And yes, it's less, given the, sort of, EPBS, but it's still there. There's… there's other advantages, so we have… I… in particular, devp2p, right? So… so this is… so Ethereum keeps kind of adding protocols, and… and… and… It's been difficult to, kind of. simplify the stack overall, and as a longer term, this one can be very clear, adopt this EIP and do nothing with devp2p. I mean, it can just be exactly what it is now, but it opens up the option to kind of start narrowing the scope of what devp2p is relied on for. So, this has a number of aspects,

And essentially, what it does, it allows a CL to… Be the, sort of, sole… sort of be the, the source of truth for the sync in a more holistic way. by, essentially distinguishing between… right now, so ELs make it difficult to tell if anything that's not… they don't have pre-state for, they don't have very much information about. Well, if you have, And there are other… I want to acknowledge, there are other ETH, etc, ETH Get BlockBy, etc. These are not spec'd very carefully, and the semantics are sometimes a little conflicting. So this, and so this sort of keeps this within the… Engine API semantic set. And… Makes it, possible for the CL then to… Kind of become…

The source of… of syncing. It doesn't address… you still need something like SnapSick, and I want to say this, it does not, so there's a lot of… this… Yelts has to do SnapSicking regardless. It's not going to sync from Genesis, typically. But it can, it can fill gaps. So yeah, that's, That's the proposal.

Parithosh Jayanthi: Thank you. Barnabas has a question if this could be an optional EIP, similar to a lot of other networking EIPs?

Dustin Brody: So… the challenge, to some extent, with optional EIPs, specifically in the engine EIPI space, optional anything in the Engine API space. Is that the, exchange capability… sorry, exchange capabilities is a talk-to by construction. I understand that, that… It has some utility, but at some level, if, if, Engine API endpoints are going to be… useful… at all, they need to be mandatory. And I'm making this point much more broadly, by the way. I mean, people don't have to agree or disagree beyond this EIP for the purpose of this EIP, but from my perspective, I'm not merely just commenting on this EIP in this regard. The other point I would make here is that we are going to be transitioning, and this is not stated in the EIP per se, because the SSZ Engine API is not itself an EIP, so there's a weird dependency ordering there, like, how can you build an EIP on a not-spec, not EIP, so…

Yep, but… realistically, by deployment time, probably, I mean, Hagota, right? We're talking… like, we will probably be using the SSZ Engine API. And part of the goal is to have that much more integrated, to simply be part of that Engine API in a way. So, I'm not quite sure… and the… so… The optionality seems of limited value to me.

Parithosh Jayanthi: Okay, yeah, that makes sense. Thank you. Any other questions or comments for Dustin? Okay, that's perfect. Thank you so much. Could you stop sharing your screen?

Dustin Brody: Sorry, yes, moment. Let's see here… Sorry. Wait, is it still sharing?

Parithosh Jayanthi: No, this is good. Thanks.

Dustin Brody: Oh, okay, great, great.

Parithosh Jayanthi: Next item on the agenda is, EIP… A3, A3 reduced CL block retention window, from Kev. Do you want to speak to it, Kev?

Kevaundray Wedderburn: Yes, let me paste, okay, you've already pasted it. Oof. Yeah, so this, EIP reduces the CL Brock retention window. The original constant was based on, max safety decay, so basically a safety decay of 100. Which, if we follow the derivation of this constant faithfully, we actually need to halve the CL block retention window, because we've just introduced 8061 in Glamsterdam. I try to check what each client was doing with respects to the CL block retention window, and it sort of varies depending on the client. Some clients store more, some clients store less, some clients don't actually have it on by default. M… I think it was Prysm Lodestar, and Grandine, but I think Pro just said that PRISM should be backfilling all the way back to the CL Block retention window. So this EIP is just, it's currently informational, to basically standardize on this, the epoch number.

It does match with the epoch number for 8252, which is the reorg retention window. And I also suggest inside of it that the CL and ELs should store all non-finalized blocks, because there was some feedback that we were using this constant to also store some backfill of non-finalized block, but I think this is… A bit footgunny, because if you don't… if you have a finality window that's more than, like, 4 to 5 months, then you just don't have any blocks left. So that's about it, it's just, it's not a… Super heavy change. One thing to also note is that the ELs are also using this constant, because some CLs do not store EL data, so they'll… they rely on the EL to store… to store enough blocks for the execution payload.

Parithosh Jayanthi: Okay, perfect. Any questions or comments? I think Barnabas also says, he would prefer if we added to any non-finality period.

Kevaundray Wedderburn: Right, yeah.

Parithosh Jayanthi: Dustin, do you want to expand on your concern?

Kevaundray Wedderburn: Consensus.

Dustin Brody: Oh, so, yeah, sure. So right now, like, there's a trade-off between, sort of, I mean, I understand we're kind of largely storing a lot of old, not very useful blocks from 3, 4, 5 months ago, and even long non-finality periods, or, like, yeah. But… in general. It's… it's possible to almost statically say that a chain that goes… is non-finalized that long is dead, and what that means is the implementations don't have to have these kind of multi… multiply-gated, sort of, but this is… Expire or prune this thing up, but only if it's finalizing. And it makes it more predictable, And this was actually one thing that was brought up, for example, in terms of… on the EL side, that people liked the idea of a predictable kind of window. So, because one of the… one of the considerations there, because Kev mentioned this, right, was that it's, like, alternative ideas, which was decided against. I personally agree… agree more with the fixed window, sure, but was, like, fork-based. So, you know, you saw the last two forks.

And people didn't like that. It was very spiky, so, you know, it would go… you would go and then drop all of Elektra all at once, or Pektra all at once, that kind of thing. So, this seems like this would risk bringing some of that back, as opposed to a very smooth window, and so there's maybe a trade-off here?

Kevaundray Wedderburn: Right, yeah, so I think the constant is being overloaded right now, right? Because originally, if it's based on the safety decay, it just needs to be a little bit more than, or, I mean, if you want to risk it to be the same as the week's subjectivity period, if we start talking about finality, there is… this seems like a separate thing. Like, we can say that we'll store 3 months of blocks for finality, or we can say all non-finalized blocks, we store them.

Dustin Brody: True, yeah. I mean, it's… it's, That's certainly an option. I'm just saying, the trade-off, though, is that it is… it is… More… it is more complicated than we have today. It is, as far as I know, and again, I'm, you know, I certainly haven't read all the client source code here, but, There is no specific finality handling, and it decouples the two. And you can say, well, we're kind of mixing the two, but the reason that the two are getting mixed is because you're proposing making this retention period much shorter. One of the advantages, one of the Things we get from having a very conservative retention period is not having to care. That was my, you know, comment about, you know, at that point, the chain is dead, so it doesn't matter anymore.

Kevaundray Wedderburn: Right, yes, I'm okay with having, like, let's say two constants then, is what I was saying. Like, if we want a long retention window, then I don't think it should be based on the safety decay of 100, because that… even that also gets halved, due to 8061. So, like, we can't just say, yeah, 4 months,

Dustin Brody: Okay.

Toni Wahrstätter: I don't… I don't think this.

Dustin Brody: That's alright.

Toni Wahrstätter: It will be halved. So I think we're talking about very different constants here. The week's subjectivity period is, as of Glamsterdam, 6 days or something, and… the constant we use with the safety decay is 36 days. So this would be on the EL side, this would be the time that we would want ELs to be able to re-og back in case there is no finality. And it feels like we should do something similar on the EL side, so probably my feeling is, like, we should use this safety decay number there.

Parithosh Jayanthi: Yeah, apologies.

Potuz: So on the last point, reorgan on the CL is actually very simple. What blows up for us when we're not finalizing is constantly reorging. and jumping from one port to another one constantly. This is what really makes the EL blow up. But making a very long reorg. just because it happened that there's… there was no synchrony, and then suddenly another chain appeared, and that becomes canonical. That's very simple on our side, and it seems to be more complicated on the EL side. So… so these two paths are fine to be separated. Also, I agree with Dustin that the current scenario is we just keep blocks for a very long time, and we set up that long time to be long enough so that we don't worry about

We don't expect not to be finalizing for that long, and we expect that that long time already covers the non-finalizing period, otherwise we anyways would have need the community to get together and solve the problem. So what I would ask about this proposal is why. I mean, what do we gain by lowering the number of blocks that we will keep on the CL side? Space is not really an issue, we're not really talking about a much disk. I just don't understand the purpose of this EIP. Even though it's… it's probably fine, it's probably fine if we just move to 8,000, blocks. But… I'm sorry, it was an epochs, I think. But still, like, why? Is this… why do we really need to change this?

Kevaundray Wedderburn: Yeah, so the original motivation was because the ELs were using it for history expiry, so I was looking at where… Why it's ready for you, or 4 to 5 months? And currently, it's… everyone uses a different number either way, or… actually, everyone just doesn't have a default behavior for this.

Potuz: Yeah, then I will target the EL side of this, and just leave the CL as it is, because it's working now, and it doesn't occupy space, and there's no reason to change the clients for this. On the EL side, of course. On the EL side, yeah, that's a different story.

Kevaundray Wedderburn: The ELs are copying the block retention window for the CLs, because some CLs just don't store the execution payload.

Dustin Brody: this is actually one of the stronger points, like, why I do find it at least somewhat motivated, like, and sort of some tolerance for it introduces some complexity because we have to care about the finalization. I think, because it has the, compensating, decreasing complexity for having to care about edge cases where the retention is differing between the CL and EL for a number of cases, both the ones Kev has talked about and some others.

Kevaundray Wedderburn: But I mean, just to bring up, one previous point, if we say that it's Freddy 3000 epochs, then we're also implicitly saying it's fine that if… If the period of non-finality goes beyond 4-5 months, then it's just, like, we're done.

Toni Wahrstätter: Yeah, but this shouldn't happen, right? That's why we have the safety decay. Like, we exactly know, like, if 75% go offline, we know that after 36 days, we will restore finality.

Kevaundray Wedderburn: So then, why are we storing… 4 to 5 months. I mean, yeah, I agree with… I agree with that the safety decay at 100 just doesn't make any sense. M…

Parithosh Jayanthi: Okay, is there anything else here that we have to discuss synchronously? If not, I'd suggest maybe a thread on ETH R&D that people could follow. Perfect. Thank you. Any other Hegota-related topics that we've missed out on? I think this means… this should be all the proposals that came in in time, but in case we're wrong, then… Now's the time to speak up. Okay. Next thing I briefly wanted to touch upon is, next steps. So, Andrew's written down some nice, information there as to how to start scaling, the EIPs, as to which tier it goes into. One proposal was that all clients have at least the first version of that tier list by mid-September. This, let's say, roughly a month from now. They should give most teams time to go through all of the EIPs, put them into different buckets.

And the way we would want to start is go with the obvious DFI and obvious CFI options, so if every client team agrees on an EIP or disagrees on an EIP, let's get that out of the way first. And once that's done, I think we start the long tail of, actually going through rough consensus and coming up with what the EIPs were actually going to SFI in the end. Of course, with rough Consensus, there's no final deadline, but I think one target is we would like to try and finish the process by DEVCON, just so that we all go into DevCon with a shared understanding of what would go into Hegota, or what could go into Hegota.

You don't have to use Forkcast, but Forkcast does have a ranking option that makes it quite easy to put buckets into different tiers. Yeah, Jocham?

Jochem Brouwer: Yes, one thing I wanted to state here, it might be obvious, but I still want to state it, these rankings, like, so we first had this SABCD ranking, now it is S, A, B, C, DFI ranking. But these rankings themselves are, like, open for interpretation, because my A is not going to be your A. So, to give an example, like, my A's are the things I really, really like. But some people could say, like, it should definitely go get in, but then S is, like, even better. So, I would say that if you publish these rankings, then at least state what is your S, A, B, C, D, what do you mean with these rankings? Because then you can interpret these rankings better.

Parithosh Jayanthi: Yes, definitely. Also, we more than welcome client teams also publishing rationale for why they chose things. That also helps navigate some differences, that different client teams would have. Okay, I think that was the entire agenda for today. Do we have, any other topics that should be discussed? Great, then see you guys next time. Ben?

Potuz: Here, guys?

cayman: VDF.

Toni Wahrstätter: Thank you, bye-bye.

Barnabé + Francesco 🚗: Bye, bye.

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