All Core Devs - Testing #87 (CL Breakout)

Transcript

Justin Traglia: Hello! Just one minute. Don't get started. We're doing a separate call, because it's easier to record. It's all automated. One more minute.

Alrighty, let's get started. Is there anything people want to discuss? I just had two PRs that I'd want to share, but they're fairly small. It's not pressing. How are DevNet 7 implementations going? Yeah, it's a whole new meeting.

Enrico Del Fante: Our branch is complete, but now we are in the process of Merging stuff from… The branch to master, so it will be… A little bit. Slow, but we will get there.

Justin Traglia: Okay, cool. How was… The stable containers changes, were they complicated to make in Teku or fairly trivial?

Enrico Del Fante: Well, no, no trial, but I had this… POC… back then… So I just grabbed it, when I started, so it's not that I started from scratch. So… Yeah, there has been… Some… some considerations, some touching point with the current implementations. So… Yeah, it was not, Immediate, but we are good enough. I run some benchmarks, and the current implementation, we can say, is generally from 1.5 to 2x slower than the non-progressive. Counterpart? So… We will probably do an optimization round to understand if that's the… overhead,

just because of the new data structure, or because it's a specific implementation overhead that we can remove. I don't know if other clients has run some… Benchmarking.

Eitan Seri-Levi: Yeah, we we saw. similar slowdowns, and we have a POC with some optimizations that get us down to about, like, 20% slower than non-stable containers. I think that's maybe the best we can do. but yeah.

Justin Traglia: Interesting. What size? like, data structures are you testing with? Are they fairly small or large? Like, a million items.

Enrico Del Fante: I have to bring back the benchmarks. As far as I remember, Well… Should have been not… not big data structure, so… Okay. But, yeah, I could take numbers back. Currently, I don't remember.

Justin Traglia: No worries. I'd be interested to see if it's the same results with very large structures, because if I recall correctly — Okay. there will be fewer hashes with large structures compared to small structures. Or, sorry, not that. I guess if the… Well, maybe. I don't recall. But if the limits are very high, then it should be faster and progressive. That's progressive loss, but maybe that's not true. Okay. Any other observations while making changes for Alpha 12.7? from anyone.

Okay. Well, there's just a couple of PRs I'd like to discuss, I guess. The first one is for something that Sproul reported a few weeks ago. There's a… Mistake and get attestation participation flags. Pretty much, I think if there's, like, a… if there's a skip slot, we, incor compute the rewards. Or, like… No. Please take a moment to review it and approve. We can include this in the next DevNet, assuming that there will be a DevNet 8. And an additional, gossip validation check. Just another dependent route check for proposer preferences. This is something that I added in the executable. Validation spec, and I am backporting to the Natural language spec.

There's just, like, a gap that I noticed Please take some time to review it as well. Right, and that's it for me. Is there anything else you guys want to discuss?

Potuz: Sorry. Can you describe the sync of the dependent route that you linked? Or do you want to review async?

Justin Traglia: Async review is fine. I mean, it Fairly simple. Let me look at it real quick. I mean, I feel like the PR description explains it pretty well.

Potuz: Yeah, so I think it's fine to reject If the… I mean, if you have such a block with a dependent root and it's from a slot, that is not even possible because it's in the future. But… Perhaps we could also just ignore if it's not… Dependent route?

Justin Traglia: You're saying, change the rejection to ignore.

Potuz: Oh no, it's changed even the condition. Like if the block is not a dependent root in any branch that we know in four choice, just ignore. The problem is that, It's a problem that we see all the time with lagging clients. Lagging clients would send valid dependent routes, because they could just say, this canonical block 3 months ago is my dependent root. My head is that canonical block. No, so the the condition above says that you haven't seen it. Nico.

Nico Flaig: So what's the difference that you mean? Sorry.

Potuz: So a lagging client, it's always the same kind of problems that I'm pointing all the time. A lagging client can say. My head is this blog from 3 months ago, and I have him just processing slots because no blogs exist. So that's a valid dependent route. And we would not, Reject it. It's a valid, well, it depends if we're finalizing or not, that's a different story. But the point is that those things are valid and still I think we should ignore. We should ignore these blocks that are based in such about old blocks. We should ignore proposal preferences that tell us my dependent root is slot 14 of the previous epoch instead of 31. Even though it's a valid dependent route, that node might be on a fork in which there has been no blocks. I still think that if our local view doesn't have that dependent route as a dependent route, we should just ignore those messages and stop propagating crap.

Early on. The condition that Justin is writing is a rejection because it's an honest rejection. The block exists and it's not even from the epoch that it should be. But I think it's easier to filter bad messages by just saying, if it's not a dependent root in your Fortress 3, just ignore it.

Justin Traglia: But how would I specify that? I mean, that's a bit complicated, at least in this spec. I guess easier for me to say, like, Or the condition right here.

Potuz: Yeah, I understand. I don't know. I don't know. I mean, phrasing, writing it instead of. Right? And it's easy. If in the four-choice tree, this block is not a dependent root of any branch, Then, oh. Oh, no, it's easy, actually. You… you ignore if… If you don't have children of that, of that slot in the right epoch. I can write it if you want. But it's a condition having children.

Justin Traglia: Hmmm. OK. I mean, if you want to write it, please make a PR on top of the slide. the executable gloss gossip foundation. Pr. I'm out of.

Potuz: This rejection is correct, though. This rejection, I think, is absolutely fine. It's one of the few things where rejection is fine because it's factually incorrect to send such a block. But I think the ignore condition is going to ignore more, more bad messages.

Justin Traglia: Okay. Anything else from anyone.

Mikhail Kalinin: And. I have a comment on the 5442 PR. So it… As it's currently spec'd out on every other station, there will be a lookup back if there is a gap. Right? Yeah.

Justin Traglia: Yep, that.

Mikhail Kalinin: So, yeah, so I'm just, the question to, CL client devs, will, will they basically implement it as is, or will they optimize and do this lookup just once? And then cache this value and, you know, read it every time. They process an attestation. From the attestation, basically, that involves this gap lookup, this gap recovery.

Justin Traglia: I would imagine that they do whatever's the most efficient and optimized. We can leave a note in this PR if you want to, like above the function. Saying that clients may optimize this XYZ. But it is sort of implicit.

Mikhail Kalinin: Yeah, of course. Yeah, because I'm asking this because there is an alternative to that. It's a bit ugly in terms of semantics, but the alternative would be to basically set the payload availability flag. or… Just once for all the slots in the gap. Yeah, kind of this one. But. And then just, what would be necessary? Basically, you do this once you fill the gap and all further attestations. will be processed without. This won't look up because the flag will already be set for, you know, and just can be read from the previous slot. Something like that. I mean, like, from the slot of the attestation.

Justin Traglia: Otis.

Potuz: this is known. I mean, this is… this was not an issue. This was discussed early when we designed this, and we decided that it was much simpler just to make those attestations Fail the… the head reward. You're… the heavy word is… There, so that we have consistency, we have… less short-term forks. And it's when you attest to the current block that it's just arriving. If you're attesting for a previous block, then this head reward is less relevant. It seems much simpler not To make this change, and just keep things as they are now.

Justin Traglia: Hmm, I was unaware that this was something that you guys have spoken about before.

Potuz: I don't know if Francesco is in this call, but yeah, this, I mean, yeah, this, this was very early on decided even at the design decision. at design stages.

Justin Traglia: Okay, I think we need more input from client teams then, and others. I mean, the fix doesn't seem so complicated to me. Yeah, I mean, it requires you loop backwards, but yeah. Yeah, I mean… Normally this won't be.

Potuz: It is about like grabbing the roots and then it just, it's just unnecessary complication. For applications that anyways… are not, like, so… Important to have the head reward.

Justin Traglia: Okay, this isn't something I can make a decision on. It'll be up to you guys. So whatever you think is best.

Mikhail Kalinin: And today we have empty slots, the, this head reward will be empty. Will work, okay? I mean, like… And the stores will get rewarded. Close to the right hand. So if we're kind of changing the condition on when the head reward is paid, I think it should be reflected in this package.

Potuz: But I mean, but the biggest issue is not like correctly voting for head. The thing is correctly and timely voting for head. The timely part is the part that is tricky with skipped slots.

Justin Traglia: I'll share the issue just for others to catch up on. after this call. It's quite a bit.

Potuz: But just just to make sure the current like in in Deneb, they get attestation, participation, flag indices. Reads that we get the block. At the slot of the data slot. And we just checked that we voted for the right head route at that slot. And we just get that the target matches, which has to be automatic. That's it. And then we check that the attestation is included one slot down. with less than one slot difference.

Justin Traglia: Okay. Protos, could you leave a comment on either the issue or the PR to allow Sprout to properly respond?

Potuz: Sure.

Justin Traglia: Alright, anything else people want to talk about? The floor is ours. Okay. In that case, we can end the call early.

Potuz: See you guys.

Justin Traglia: Bye, everyone.

Dmitrii Shmatko: Bye.

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