All Core Devs - Testing #94 (CL Breakout)

Transcript

Justin Traglia: Hello, hello. Just one second, and then we'll get started. Maybe 15 more seconds, and then we'll get started. All right, the first item on this… on our agenda is this PR, which I just shared. Oh, actually, I shared the wrong one.

This one, which adds a new, gossip check to the bid, gossip validation function. This is… the issue is that A builder which has an exit. In, like, the previous slot, which is, like, the parent's payload. Will only be applied like… After the beginning of… The current slot, or however you define it. And therefore is, like, unknown at the time of bid gossip checks. This would lead to a missed proposal if a proposer were to select this bid, which would be considered invalid in the state Transition function. I, just in the PR I made, I applied builder exits, which, were forbids from that builder. Nico had a suggestion to… Simply ignore bids.

Where there exists a builder exit. In the previous slide. Nico, you say you don't miss the proposal, though, you just fall back to local. Oh, is that true?

Nico Flaig: Yeah, I mean, at least in Lodestar, we run the state transition on both blocks, and then we would just determine the builder block is invalid, and then pour back to local. But yeah, you would not consider any other bits, I guess, if that bit, was the highest one.

Justin Traglia: Yep, that's true. And your suggestion, I'm trying to recall, is… Sorry, if you were to just ignore bids from builders which have an exit, is there a way that someone else could submit an exit which is invalid? Mike. Could you prevent another builder from being selected? I recall.

Nico Flaig: Yeah, that… that might be right, yeah. We… I think we do the source address check on the, in the process builder exit, right?

Justin Traglia: Yes, we do. If builder execution address equals… or, sorry, does not equal request source address return. So we would have to add that, too.

Potuz: I'm sorry, what was the concern?

Justin Traglia: I can… let me share my screen and I can talk about it. Can you see it?

Potuz: Yep.

Justin Traglia: Okay, so the concern is that if a builder submits a bid, And… and they have an exit in the pre… in, like, the parent's full payload. It would be accepted by the proposer. But then when the proposer tries to use it. It wouldn't actually be considered valid, because the builder will have exited, because apply parent execution payload envelope It's done after.

Potuz: Yeah, so that's the issue that Michael, like, raised today, I think, on the email, but I didn't understand what was your concern about like, what is the greeting scenario here? Like, the builder exiting so that it prevents another builder from landing a bid in the next block?

Justin Traglia: Well, you could prevent another builder from… yes. I'm getting the bid. You could submit a… Okay, so say… how do I say it? Like, you could submit a bid for 100 ETH to prevent all other builders from getting that. Or from winning the bid Does that make sense?

Potuz: Yep.

Justin Traglia: Yeah, I mean, I think it's important that we fix it. It's not really a… breaking change, since it's only gossip. I guess it's just a matter of how to do it. Like, are we okay with Simply applying builder exit requests to the state. Or should we do something a bit simpler, where we just ignore all, Exits for that builder.

Potuz: I don't understand, so… so what you want to do is to fix it at the propagation level of the VD itself? You want to avoid this bit from propagating?

Justin Traglia: Yeah, I would like to avoid this bit from propagating, but also just… I mean, it would, Video, sorry.

Potuz: done a lot of complexity for an attack that is… again, I feel that we're over-complex… making complex a topic that is barely used. we can just handle this at the client level. Direct connections will keep the bids, you can keep more bids than one. There's a bunch of things that you can do, and… yeah, I don't know, it seems silly to try to fix this stack.

Justin Traglia: I mean, it's so simple to fix, though. Like, it's really not that complicated. We shouldn't leave a… a mistake. Earned oversight and, gossip checks.

Potuz: But, I mean, the point is that you can fix it by… Just keeping the bids. Like, you… when you are about… so you keep the pool of bids, and you make a selection of bids at the time of proposal. It's true that this will prevent some other P2P bids from propagating.

Justin Traglia: And… Yeah.

Potuz: Yeah, okay, so I think we're always going to be on the… on different ends of the complexity that this Path should satisfy. So what is the fix that you guys are proposing?

Justin Traglia: Either ignore, Bids from builders that have an exit in the previous full payload, or just to apply builder exits from the previous full payload. Before, checking to see if the builder is active.

Potuz: No, booth. So, the first one is not so bad, because the payload, we… we should have it anyways in memory, and we can, like, run a loop over every bit. Or at least write a map on the payload and just check existence on the map. Like, applying the… applying the… the pre… I mean, the request from the previous payload would be essentially, like, having to deal with the caches that we had pre-5094. Like, if we go to pre-5094 over this, that would be crazy. I think it's fine, probably, to have a map. Most probably, I don't know, probably Terrence will implement this. Most probably we would just not care about this.

Justin Traglia: I think I'm gonna change this so that we don't mutate the state, and just, at this check. Pretty much. Like, Check to see if the builder hub key is the same, and check to see if the execution address matches. And then ignore, like Nico suggested. I think that would be simpler, and you don't have to keep, like.

Potuz: No, no, so you want to change the state Transition function over this?

Justin Traglia: No, no, I don't. No, I don't.

Potuz: Prevent…

Justin Traglia: Got it. I'm adding… this to… here instead. So, like, if the pub key matches and the source address matches, ignore.

Potuz: Yeah, so that means… so you're adding this change within something that is on the state Transaction function, right? So this is on processing the previous payload's requests.

Justin Traglia: No, this isn't… Gossip, the gossip validation function for bids.

Potuz: The gossip validation function for beds, let me see, oh, shit, I need my glasses. So, what they have to say? Sorry. Correct, impressive. Oh, okay, so you're, you're taking… So you're ignoring the bid that has an exit in the previous payload.

Justin Traglia: Pretty much, yep.

Potuz: Yeah, yeah, that's… so that, I think, is the easiest solution. We can write a map And keep a map. Of the… of the addresses in the previous payload. I still think it's a bad idea to do this, but anyways.

Justin Traglia: Okay. Alright. Do other clients have feelings on this, before moving on to the next agenda item? Okay. Moving on, Sorry, I would like to discuss with you guys a way of just… sorry, that we should, or how to test on DevNet 8. A payload with more than 8,192 deposits. PK? Is this something that you'd be interested in doing? It's a… it might not be so easy.

pk910: I think we have a sort of playbook for that. Should already work with tournet. Million gas. Oh, no, this gas schedule has changed it again. I can try, however big I can get it. It has a batching contract and everything inside, so it's pretty much maximum that we can get.

Justin Traglia: Okay. Awesome. And I mean, I would be interested in doing it myself, but I don't think I have enough ETH anymore. I would need more than 8,000 ETH to do top-ups, right?

pk910: Oh yeah, I can send you some for sure. Just drop me an address.

Justin Traglia: Yeah, will do. Thank you. All right, cool. I'm excited to see that. Jihoon, we… we said that we were gonna… that we were gonna discuss the HESI, Gossip condition? Are you still here?

Jihoon Song: Yeah, could you remind me what the gossip condition was?

Justin Traglia: And the CL checking that there are no empty transactions.

Jihoon Song: Right, so, in EL gossip rules, we check whether the list of transactions exceed 8 kilobytes, but in addition to that, we're thinking about… I mean, we are entertaining the possibility of adding a new gossip track that See if any transaction is empty. Yeah, thanks, Justin. Deadline, even without the check. EL will kind of just filter out empty transactions, so nothing's really changing, but yeah, we can add that condition in the gossip rule if people like it.

Justin Traglia: I have a dumb question for clients. So we have the defined list of checks for gossip messages. Do you… do you essentially buy the same checks to request in response? Messages as well.

Jihoon Song: I look into this… duplicate before? And… we have, like, not exactly the same, but many overlapping conditions for… if I'm not wrong, it was a PTC message, because… no, it's not a PTC message, it was… I forgot. There's one object that you can get via requested response. and or over pay-to-peer. Then, you need to have a check For that object that you received. Via request response, so we have to write the same check over again. Because you were gonna pass that object to the handler. Whether you got it from rust-response or P2P, And Inclotential List is in that situation. That's why we need to kind of duplicate certain… This… this checks.

Justin Traglia: Okay. clients that, have worked on HESI, are we fine with adding such a check? I mean, it's very basic.

Jihoon Song: I just checked, and it's, it's executed by another envelope. So we checked some… We have some checks that we… applying P2P in verify execution payload envelope function, so if you look into that function, you can see some… some overlapping checks.

Justin Traglia: Okay. I mean, you don't want me to do that right now, correct?

Jihoon Song: Yeah, we don't need to. It's just for me to explain why we need to duplicate some of this. gossip checks.

Justin Traglia: Yep. Any comments or thoughts on any of this from clients? Do we need to talk… do we need to talk more about this new inclusion, or sorry, the updated inclusion list max size? Variable. Okay, Jihoon, I think we can… we can handle this. We have enough information.

Jihoon Song: Yeah, I think we can just add states. non-empty assertion, it's not really a big of a deal. And then we can just start with this 4112 limit. And, yeah, I can… I can clean up this PR, I'm a salespec PR, but I cannot… clean up, enginePIPR, I don't have permissions, I'm probably gonna open a new one. And… yeah. It is not part of Alpha 14, but… If you are working on Fossil Tembinate Zero, please also include these changes. For fossil 11 at zero, and then… Yeah, let's discuss how that definite went tomorrow in our breakout.

Justin Traglia: Yep, thank you, Jihoon. And remind me, you were not a fan of this, fork choice. assert, correct? We can delete this, it's not necessary. Keep it just…

Jihoon Song: stage? I think it doesn't matter, I need to… I need to think more about this if we were to remove it, but I think it is correct to include it if we were to have that Non-empty check and peer-to-peer rule. I'm fine with having a fork choice. If you weren't to end it in peer-to-peer.

Justin Traglia: Okay, sounds good. Yeah, we can discuss this more after the call. There is another topic that I would like to discuss. Otis, on Discord, you said that Prism is using, like, or 60% of Prism's time is spent.

Potuz: No, no, don't listen to prison. That was my personal node running a different client.

Justin Traglia: Oh, it was not present. Do you feel comfortable saying which client it was, or is this…

Potuz: It's just a C++… branch that I have. It's a very good branch, it's performing very well, but it's led me to find a bunch of issues with Lighthouse, for example. banning peers that don't consume faster messages. That forces me to, like, move from a one thread to several threads to deal with gossip messages. I wasn't aware of that condition from Lighthouse. And this is another one, which I'm pretty sure that should be true for most clients. Like, there's a burst of PTC messages that you get to see, and it's surprisingly large. I don't spend that much time validating attestations. The biggest time that my CPU is spending in validating things over gossip is A KCG from data columns, and B, PTC attestations.

Justin Traglia: Have any other… I'm sorry, have any other clients looked into this? Is this using a lot of resources on their client as well? PTC, message handling.

Potuz: Just to be clear.

Enrico Del Fante: buddy, Dave.

Potuz: The problem is that this is in the… so, I had this on the foreground, because I dismissed it at something that should be very fast, and it wasn't, so that forced me to move it in the background. And again, this is perhaps a technical point, but the thing is that if we manage to have things single-threaded. then we don't need to lock for choice at all. We can just deal with the single thread that manages 4Choice. And that takes away a lot of complexity from the client. That was my design decision for this particular client. And I could not take it because I could not handle PTC attestations on time to drain the gossip socket

From my peers that would otherwise ban me. So, I knew that data columns needed to be removed, and that was fine, because it's easy. That requires just a little copy of a little piece of fork choice. And that's fine, but PTC is more complicated because it requires to know which are the PTC members. And I wasn't happy locking purchase to remove that from the foreground and move this in a separate thread. Once you have PTC attestation's validation on a separate thread, then it doesn't really matter. As long as you have more than one core, your computer would just, like, validate fine.

Justin Traglia: Okay, thank you. Enrico, you were about to say something?

Enrico Del Fante: Yeah, I was about to ask if… So it's pure fork choice, internal, validation of the PTC was not just, I don't know, I don't know, BLS… Senior verifications…

Potuz: No, no, no, it is BLS, so the most… most of it is BLS. The thing is, you get a message over gossip, and you need to do gossip validation to rebroadcast it or not.

Enrico Del Fante: Yeah.

Potuz: And the question is, do you want to do the validation before you release the socket from your peer, or you do it in the background and you just consume the message from your peer?

Enrico Del Fante: Why is it not happening, like, in attestation aggregations for you?

Potuz: So this happened at PTC, not an aggregation, so validating PTC messages.

Enrico Del Fante: Yeah, yeah, yeah, but why you are not seeing the same behavior on, like, attestation messages, which should.

Potuz: Oh, because they're less. It's surprising, but they're less. So you're registered only to a couple of subnets, so you don't get many single attestations. And you do get a lot of BTC attestations. Okay. So subnets is actually doing its job for attestations, but we don't have subnets for PTC attestations.

Enrico Del Fante: And the global, aggregated attestation are still less.

Potuz: Yeah, because we are… so this might be an issue just on the DevNet. I think we're just very effective on the DevNet. You see most blocks, except Prism, that has a bug that is already fixed, we see most blocks with only one attestation.

Enrico Del Fante: Oh, okay, okay.

Potuz: So, so the aggregates are really good, and yeah, so they don't consume time. I actually, I only fork away, crypto, to the, to the background, so BLS, and KCG, And it's performing much better, and it's a much simpler client than having to deal with threats.

Enrico Del Fante: Yeah, we should do, our own… Check, for sure. How are we… are we performing there? We don't have these high defects. You have in your client, for sure, but, checking… Checking how are we behaving should be… Good to check.

Justin Traglia: At Potus, you mentioned that KCG is using a bunch of time on your CPU. I just wanted to share a project I was… I made, like, 2 weeks ago, where, the GPU does the proof computations and whatnot. It's been pretty neat. Okay, anything else we'd like to discuss? We have 6 more minutes left. All right, thank you everyone for joining. I'll… back to you guys on Thursday. Bye, everyone.

Enrico Del Fante: Bye.

Luca | Vero: Bye.

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