All Core Devs - Testing #95 (CL Breakout)

Transcript

Justin Traglia: Hello, hello, just one more minute, and then we'll get started. Alright, this should be just about everyone. I'd like to go around the room real quick and just get updates, from client teams on, like. Where they are regarding… spec and testing, like, have you all updated to the Beta 0 release, and are you running all of the tests there? Lodestar is running all the tests, even the fork compliance tests, awesome.

Enrico Del Fante: Ekko, we are still, implementing Deltas, Delta spec, so we are in the process of… Implementing everything, we will enable, reference test running, Hopefully soon. And I believe there is also, some work on running more, frequently the… the reference test for… for… for choice. It was com… compliance check, yes, compliance testing. Not yet fully integrated. But yeah, work in progress there as well.

Justin Traglia: Okay, cool, thank you. I guess James, James shared the PR for PRISM earlier, so I know that's a work in progress, and they haven't merged it yet. I'm surprised to see that there are some things from Alpha 13 and Alpha 14 there, too. Why, just out of curiosity, why weren't those there before? James Or Terrence. If he's here. Okay. I guess, James, you don't feel comfortable speaking about this, or… Alright. Is there someone from Lighthouse here? Maybe… Daniel?

Daniel Knopik: Yeah, but I'm actually unsure. how far along we are at Eton. That's probably the one… I'll ping him, maybe he'll respond.

Justin Traglia: Okay. Thank you. Grandine? Saulius?

Saulius Grigaitis: Yeah, sorry, I joined later. Could you repeat the question?

Justin Traglia: Oh yeah, I'm just asking for, client updates on specs and testing. Have you implemented everything for the Beta Zero release, and are you running all of the tests?

Saulius Grigaitis: I think Wangleng started to work on that, but I doubt that it's completed, but we started.

Justin Traglia: Cool. Any other implementation or testing updates before moving on to the other agenda items? Does every… Nico's asking, does every client run the basic fork choice tests and pass them?

Saulius Grigaitis: Do you mean compliance tests that have photo choice? This is what I think he…

Nico Flaig: They're really just the basic one, yeah.

Saulius Grigaitis: Yeah, the basic one that I'm actually interested in the compliant tests, suit. Is everyone running, and everything is passing, or this is still… And, not fully adopted.

Nico Flaig: Yeah, I mean, we pass all of them now. There were some bugs in the spec, so Beta 0 has everything fixed now. Or should have everything fixed.

Saulius Grigaitis: Okay.

Nico Flaig: Yeah, I'm just asking for the basic tests, because, like, the last time I was running Death Star, there was still a lot of attestation modes that were incorrect, due to, like, PTC stuff missing in clients. And before clients have the basic tests and pass them, I don't think it's worth to do another testing round. On the definite, at least.

Enrico Del Fante: I mean, so you're saying… you're saying that the… the… with… with, so you're referring to not the compliance test, but the normal reference test.

Nico Flaig: Yeah, really, just the bare minimum, yeah.

Enrico Del Fante: Yeah, yeah.

Nico Flaig: import, like, Arteku is fine.

Enrico Del Fante: We were using… we were, yeah, we were passing them for a while. Now Beta Zero is still a work in progress, so we have several things to… Fix, but we should,

Nico Flaig: Yeah, I mean, for the compliance, you need also a lot of other stuff, right? Like, should I.

Enrico Del Fante: Yeah.

Nico Flaig: also boost and stuff like this. I'm not sure everyone.

Enrico Del Fante: We did, Historically, there was a consensus team working on the compliance, so we were running them earlier, so… basically, I remember we were… we were passing all of them, but probably, currently, we have some problem in integrating with the latest version, and there is, our colleague… colleague of us is working on that, so I don't know if it is something just an integration, or… some weird case. Not sure yet.

Justin Traglia: Nico, which complaint… which clients do you have complaints about regarding WorkChoice?

Nico Flaig: So last time we tested this on the DevNet, it was, Grandine and Nimbus. But it's a while ago, so I really can't tell if those issues are still there or not.

Justin Traglia: Got it. Okay, let's move on to the next agenda item. Nico or Stefan, would you like to talk about… Your PR, bound the bid's gas limit against the parent execution payload. I'll share a link in the chat. Why should…

Nico Flaig: We do this not in the core, by the way.

Justin Traglia: Oh, oops. Okay, well, Nico, would you like to discuss why we should not do this?

Nico Flaig: I mean, is anyone in favor of doing this? I don't think it's worth arguing why we shouldn't do this. Just doesn't make any sense. I already left a comment on the PR, but initially, right, when we added this, if you look at POTUS's initial PR, we had, like, 3 options. If we want to make this part of consensus or not. like, on the CL side, part of the consensus rules, But we decided to not do this, Because also it encodes, like, the EIP1559 transition stuff, and it's just unnecessary, like… I would like to, I guess, know why we should do this. Is POTUS here? I mean, if POTUS is here, he definitely doesn't like this.

Justin Traglia: No, he's not here.

Nico Flaig: If there's nobody else, I mean, if nobody's in favor, I guess, to do this.

Justin Traglia: Is there anyone that's in favor of doing this?

Nico Flaig: I mean, have you read the PR description? Even what's noted there doesn't make any sense, so… I don't… Yeah, let me skip.

Justin Traglia: unit. Proper chance. I'm probably just gonna close the PR, unless someone here speaks up.

Nico Flaig: So just to, the issue came up initially because, Stefan did some testing where, basically the same node that was used for proposals also was used by the builder. So the builder submitted, basically, these bits to the Beacon node, and then it picked it up. Because we intentionally don't do those checks on the API, because we want to publish early. And in Lodestar, initially, I still submitted them to the pool, just for debugging purpose. Because, I mean, for mainnet, it's not relevant, right? If you're the same entity, a proposer and a builder, then whatever, you don't care about a bit submitted via API. But this code path is now also removed, so… This cannot be flagged by AI anymore.

Enrico Del Fante: So, I haven't read the discussion, so it's possible that we could have a bid on-chain with… The wrong gas limit?

Nico Flaig: So, essentially, it's just…

Enrico Del Fante: problem?

Nico Flaig: So it just says you put a bit into a block that has an impossible gas limit.

Enrico Del Fante: Right, so…

Nico Flaig: Mark Steel and success.

Enrico Del Fante: will be a… You will be… you will have the corresponding payload, invalid. For sure, correct?

Nico Flaig: Yeah, you cannot produce a payload that would pass that.

Enrico Del Fante: Exactly, so you are guaranteed to have an on-chain, a Beacon block with a wrong bid, and you will know in advance that it will not… it will be orphaned, so it will be an empty one. And move on. Yeah, it's… I don't see this thing to be super nice, necessarily, at the moment. I agree.

Nico Flaig: Yeah, I mean, the gas limit check, we only added that on the CL side to make sure the builders follow the preference of the proposal, right, in terms of, like, where they move the gas limit? Yes. And to filter out, like, bits that do not go in that direction, yeah.

Enrico Del Fante: Hmm…

Justin Traglia: Yep. Submit a very high bid with an invalid gas limit.

Nico Flaig: I mean, a proposal would even be incentivized to take that, right? I mean, no client should include such a bit by default, because you should validate that it follows, like, the… Yeah. But I think it's more of a risk to validate this in the CL state transition. Like, then a bug could cause a missed BeaconBlock for no good reason. So…

Enrico Del Fante: Yep, we don't need to… Yeah, we are risking the Beacon… the Beacon chain moving forward. Just for something that makes the payload invalid.

Nico Flaig: One example, yeah, exactly. One example we can also never verify is, for example, impossible hash, right? Like, if someone, a builder, wants to do this impossible bid, they can just put in a zero hash, or whatever. You can never produce such a payload, right?

Enrico Del Fante: Sure. So, yeah, there are several paths in which… You're guaranteed to have something at that end in the payload. But still, the BeaconBlock is valid, and we can move on with the CL. Consensus, yeah. Okay.

Justin Traglia: Yep, let's move on. I'll close the PR after this call. I agree with you guys. We agreed on Discord that we don't need to discuss the build or producing an invalid payload topic that was handled async. Nico, would you like to talk about your other PR, titled Only Seracanonical Payload Envelopes by Range?

Nico Flaig: Yeah, so that one is a really old topic, that was earlier discussed on Discord, that caused a lot of trouble syncing, because clients basically served payloads they shouldn't serve. I thought we kinda addressed this, but on Defnet 9, when syncing through the unfinaled period, there were a lot of invalid payloads being served that shouldn't be served. So this was all in the finalized part of the chain, so my guess is that clients don't filter correctly when they archive payloads. I mean, this just clarifies it on the spec side, just adds a note.

Enrico Del Fante: Yeah, did you double-check that on the… for… for the nodes serving those orphaned… Payload, though those nodes were actually up to date. Because our initial thought was maybe… we served very few of them, so, since DevNet 9 were DevNet pretty… pretty struggling pretty a lot, there were probably several technodes on… in difficulty, so maybe you got those orphaned from those? nodes.

Nico Flaig: So you mean those nodes were sync… syncing themselves, or…

Enrico Del Fante: Kind of thinking, or not thinking, but super struggling, yeah, far from… from the head, and maybe kind of, struggling thinking, and following the chain.

Nico Flaig: But at least the data I collected, because that was pretty early in, like, the sync, it was maybe a few epochs even just after the glorious fork transition.

Enrico Del Fante: Okay.

Nico Flaig: I didn't even… they shut down the DevNet before I got to HAT, so…

Enrico Del Fante: So, you're saying that those blocks were, I mean, prior lead blocks.

Nico Flaig: Yeah, they were, like, really old, like, one day or something old, so…

Enrico Del Fante: Yeah. We should have… yeah, probably they should be low, but anyway, we got problems very early in the… in the gloss transition, so yeah, probably worth having. A double… another test on a much stable… Much stable network, I believe.

Justin Traglia: Nico, did I see criticisms of this PR from Botus on Discord? I seem to recall that, but I don't recall.

Nico Flaig: I mean, he just said he wants to get rid of the whole payload topic, so…

Justin Traglia: -Oh.

Nico Flaig: But that's his, other CL zync EIP, right? So, we are not doing that, so…

Justin Traglia: Yeah, not right now.

Nico Flaig: I mean, he said he doesn't… He doesn't want to review it, so I don't know, I guess someone else needs to review it.

Justin Traglia: Yep, okay, others, please take a look at this PR and approve it, or review it. We can get that merged soon, if there's… If enough clients approve. Okay, I think that was it for the agenda. Is there anything else that we would like to discuss? Any random topics?

Daniel Knopik: I recently stumbled upon the fact that The new limit for, like, gossip limit for… Columns is, like, 8 point something megabytes, which… seems… like, I get that it was probably just, you know, the old cell limit, multiplied by cell size, but with, like, the current blob limit, it seems, like, ridiculously large, and yeah. I was wondering if there's any history that I missed, why they, you know, it was picked up.

Justin Traglia: Yeah, I think I know what you're talking about. That's the maximum, like, P2P message size of the encoded SSC.

Daniel Knopik: Right.

Justin Traglia: That's gonna be whatever the absolute maximum is, so it's probably assuming, like, a max of 4096 blobs.

Daniel Knopik: Yeah.

Justin Traglia: Which, yes, I totally agree, it's like,

Daniel Knopik: I don't think it makes sense to set that limit right now, like, we can just, like, even accounting for 100 blobs. It's… it's larger than needed, but we can, like… I'm considering, like, proposing to lower it. And, like, if we later need more space, then we can just change it in a future fork.

Justin Traglia: Okay, how do others feel about this?

Enrico Del Fante: I feel like… That's a case in which we should have something more dynamic based on current BPO, do you feel? Seems like a very hard, hard limit, which doesn't take… Doesn't care about the actual network configuration. So, maybe we should, shouldn't he? Shouldn't it add to… we should add something more. Specific.

Daniel Knopik: I'm fine with that as well.

Enrico Del Fante: Mmm. So if you want to have something that works no matter BPO we decide to have, well, it's fair that the current BPO doesn't even consider those large numbers. But whenever you change that, you need to always think twice, and are we going more than the SSD max configuration? Otherwise, we need to just have that theoretical limit, and have instead something more dynamic based on the current BPO. That are just my thoughts.

Daniel Knopik: Yeah… I just want to avoid, like. Like, having this limit in the spec, and then every client sets another limit to, like, try to mitigate some… Possible attacks or something. Because this is just, you know, way, way too large, and… Yeah…

Justin Traglia: I see what you're saying.

Enrico Del Fante: It's a more practical way of dealing with it right now, before having something different. Yeah.

Justin Traglia: Yeah, I just don't want to have a limit that we have to adjust, like, every other fork, or every fork. Not me.

Daniel Knopik: Sure, but… I mean, if we're adjusting the max blob count anyway, I don't think there's much harm in having to adjust that one constant as well. I mean, I don't… I don't really… we can make a, like, define a function in the spec and… and just do right. that or something. I'm good with that.

Justin Traglia: Probably what I would do. I'd probably just, Set it to whatever the largest value in the blob schedule is. blank.

Enrico Del Fante: Yeah. That could make sense.

Justin Traglia: Is it possible… or sorry, this is maybe, like, an implementation question, but I know, like, gossip topics have their own, like, message size limit. If the limit changes, do you have to, like, reinitialize the topic handler?

Enrico Del Fante: Yeah, that's definitely another technical problem. I guess that…

Justin Traglia: That actually might not be an issue, because if you change the blob schedule, you're probably gonna restart. The note, right?

Daniel Knopik: We just pick, like, the limit for the largest block, parameter change that's scheduled, and pick… take that one.

Enrico Del Fante: Yeah.

Justin Traglia: Okay. I mean, I like my idea. Of course.

Enrico Del Fante: Definitely, it will signal the problem, and then a client will chime in and double-check and say if that's technically… an issue to implement, or not. I would… I would suggest you, yeah, go in that direction, and then we can refine.

Justin Traglia: Okay, sounds good to me. I can… I can work on that. Thank you, Daniel. Is there anything else we'd like to discuss? I have a random question. PK, did we ever test a… A block with more than 8,192 deposits.

pk910: I think it's no longer possible with the, guest limits. Do we have right now? Or with the gas price. It was possible before, but I've tested, and I didn't get to 8,000.

Justin Traglia: Okay. I guess that's fine.

pk910: It was somewhere below 7… 7,900 or something.

Justin Traglia: It would be nice to see one with more. We can handle that later. We could just test this on kurtosis, too, yeah. As suggested by Nico in the chat.

pk910: Yeah, there is also a spammer scenario included in SpamR that, basically spams the presets via a batching contract.

Justin Traglia: I don't think I was able… ever able to get it to be above 8,000, at least on my computer. I don't know if it was just, like, a performance thing or what. Okay, anything else? Alright, let's wrap it up. Thank you for joining. Bye, everyone.

Enrico Del Fante: Bye.

Nico Flaig: Bye. Yep.

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