All Core Devs - Testing #89 (CL Breakout)

Transcript

Justin Traglia: Hello, just one second, we'll let people join. Alright, I think that's everyone. Alright. There were just two PRs which I wanted to discuss. One from Nico and one from myself. I'll share my screen, just one second. Alright.

Nico, if you're here, you can chat about this. If not, I can.

Nico Flaig: Yeah, I can quickly mention the main purpose of the PR. So, as the title says, we want to allow multiple bits from a single builder over P2P. Specifically, I highlighted that in the PR, why going with the number 3? Which is, basically, the builder doesn't know what the proposal will end up proposing on. So, to cover all cases, especially if there's, like, a PTC split view or WCAT, you basically have to provide the bid for empty, and if there's a payload also, you need to provide one for full. And then, also, in case of an honest proposal reorg, you would also need to supply a bid for the parent. Which has, like, the payload status resolved already, so in that case, you only need one.

I previously had this to even cover at least two branches with a different head. But Portus was not so happy with that, so I removed that. I think. Having just 3 is probably enough. I think the only… I mean, the consideration is, like, implementation complexity, but we already have the, sync… No, sorry, the… the high-value, tracking via slot, parent root, and parent hash, so I think… yeah, I also saw in Prism, it seemed pretty simple to implement this. Also, Lordstart was trivia, And the other consideration is just the DOS vector, but I really don't see how that's a problem. Also, there's another question related to that, which is, we have this node in the spec to prevent, like, DOS. It's only a node on the spec.

I was just curious if clients implemented that. At all right now.

Justin Traglia: If in the future we needed to increase max bids per builder to a higher value, we could do that at any time, because it's not consensus-breaking, is that correct?

Nico Flaig: Yeah, right. So that's the other good thing, so even that change is completely backward compatible. You can even release that if we had the other spec on mainnet, because it's an ignore rule, and also, yeah, it allows more bits to go through, so… yeah, you can basically always increase that.

Barnabas Busa: Could we also just disable EPBS if we just set this to zero?

Justin Traglia: I mean, theoretically, yeah. I don't know why you would, but… Yes.

Barnabas Busa: I mean, Portos has been joking that his next, fork idea is to rip out TPBS. I don't like change, basically.

Justin Traglia: I haven't heard that, but… funny. Nico, in general, I support this because I think it makes, P2P builders more competitive. And I think that's the only rationale needed.

Nico Flaig: Yeah, just to give some more context, so, I have an EPF project that builds a Lodestar Builder, and I realized this, basically, that we, like, to make it properly, like, to… I'm not sure Builder does this currently, but… you really wanna support multiple branches on P2Pits, and then I realized, oh, current spec kinda requires you to at least have 3 builders on-chain. To cover these cases, because we have this bit rule, to only allow one bit.

Justin Traglia: Yeah. I was also thinking, like, what if we relaxed that rule so that builders could just submit three different Or, sorry, so builders could just submit 3 bids, regardless of the… parent block hash. And parent block route. But, I think this is a bit more restrictive and probably in a good way. How do other clients feel about this change? Produce?

Potuz: So, I want to give an argument against this change, but also, it's not really against this change, but actually against the current spec. Oh. The way we have our cash now is that we… we keep a highest value for a pair of Block and hash. And already this is bad enough that it allows builders to propagate beds And keep increasing the value without the fear of them being included, because if there's an overwhelming Already decision on the chain on what's the head view. Then they can keep increasing the bid value on the non-head blog. And try to bid on that, and those bits will propagate because of the cache. So this PR makes this strictly worse, in that a builder might just keep increasing the value and keep DOSsing the P2P stack with bids.

For blocks that can never be proposed by an honest proposer. And we won't stop this. I believe that the easiest, safe way of dealing with the P2P stack for bids would be that you propagate the best bid that you have seen Compatible with your head. And nothing else. So this already takes care of multiple bids on multiple branches, and multiple bids on cases where you're reorging. I know that there's a subtlety between honest… get proposer head and your head, but again, this… this, I think, is much safer than allowing builders to keep increasing the bid on a bid that will not be selected by proposers.

Justin Traglia: I actually agree, and POTUS. Er. Sorry, your hand is still up.

Potuz: Oh, I'm sorry, it's this damn client, I need to lower it myself.

Justin Traglia: No worries. I mean, what you said actually makes sense to me. But they should just keep track of builds, or sorry, bids. That work for their head. How do others feel? Nico, would you see an issue with that? Or would this also work?

Nico Flaig: So it's basically saying instead of using the parent state of the parent block route, I guess, you… in the bit, you use always the headset, right? And ignore if it doesn't match.

Potuz: Right, so probably the best the best way would be, but that I think it's actually more complex than implementing your PR, but the best way would be, to check if the bid is building on top of your GetProposer head.

Justin Traglia: Okay.

Dustin Brody: Question-with this? Oh, sorry.

Justin Traglia: There you go, please.

Dustin Brody: Okay. What… I'm not sure if I'm understanding this correctly exactly, if… would this, apropos, the, you know, on… on proposer head, or on the builder's bidding on multiple… on top of multiple, or… Right, whatever, I'll… clarify if I need to on that phrasing, but, builders building on top of, multiple branches. in general, it seems to sort of invert, the sort of control a bit, I guess. The… the… for everything else, like, the general flow of control has been towards the proposer deciding, like, the… well, the fork choice, I guess, most literally, but this is an example of that. It seems a little odd for builders to suggest something else.

Potuz: No, I think it's… it's… it's… this is not changing, even with this PR, so… builders don't really know what the proposer's view of head is. It might be different from them. So it does make sense for builders to already produce blocks on top of different heads, because the proposer, when they call them and say, I want to be… I want to get a bid, give me a bid for now, this is for direct connections. Then the builder would already have all of the possible questions that the proposer would ask already answered. So the proposer is the one that decides over what is proposing, and the builder needs to sort of, like, prepare different blocks in parallel to be able to

To provide those blocks. Now, over P2P, we already allow the builder to submit different bits. And if there are proposers, if there are peers that have different views of head, they will propagate different bits. So that's why I prefer this, just propagate one. your best bit, just one, don't allow multiple bits, but you propagate the best bit that is compatible with your current head. So if there are viable heads, then bits will be propagated for different, for different, blocks. This PR takes a different instance in saying, even if it's not the best bid, you should propagate it, because the proposer might find it more useful. So this makes… makes it such a way that you are allowing more traffic over the P2P stack, which I think is inherently less safe.

Justin Traglia: I do agree with you? But I do think we should allow a single builder. To submit multiple bids. So I think we'd still need to keep the max bid. So then…

Potuz: But that's allowed already, Justin. There's no… nothing that prevents a builder from submitting different bits. This is not forbidden in our… not forbidden in our BDP stack.

Justin Traglia: I mean, it is, it's the… this is the first signed bid seen with a valid signature from the given builder for this lot.

Potuz: Yes, but the thing is that you will not… so, different peers would see different beats. That's the whole point. You see?

Justin Traglia: I know for…

Potuz: I only propagate my head, I can only have a single valid bid from this builder, because I only have a single head. But different peers will have different heads, and those two different piers would propagate different bits.

Justin Traglia: Yes, I agree with you. But the builder would only be able to submit one.

Potuz: No, the builder would submit different ones to different peers, and then the different peers will choose the right one.

Justin Traglia: Oh, wait, I think I understand what you're saying. Are you saying that they would ignore it because it doesn't match their head, and therefore it wouldn't be a valid bid?

Potuz: Yes.

Justin Traglia: Okay, so they were just never…

Potuz: nor before this one of the.

Nico Flaig: Yeah, but you don't know the head the proposal's gonna pick, right? Like…

Potuz: No, you do it by your head. You're a peer in the network, and you do it with your head. If the proposer has… agrees with you on your head, then eventually we'll just get your bid. But if the proposer doesn't, and that head was actually viable, then the proposer will get it from a different set of peers. The point is that…

Nico Flaig: even if.

Potuz: If heads are viable, then beads should propagate across different paths.

Nico Flaig: Yeah, but the problem is, even if every node agrees at slot N, and they have the same head at slot N, you still cannot cover all paths the proposal can take at slot N plus 1, so you cannot cover everything.

Potuz: Well, you can, because if there's a complete agreement on slot N on what the head is going to be at N plus 1, then the proposal cannot just change the head of the view of the whole chain.

Nico Flaig: that relies on proposal boosts and stuff like this, like…

Potuz: Yes, that's the proposer… that's the… that is what I mean by GetProposerHead. By the time that… by the time that the bid is being propagated, then the view of the chain is already set. If only one head is actually viable, then it's fine that we only propagate on that only head. If there are two heads that are viable, we will have peers that have that other head as head. And I agree with you that there is this subtlety that If the block is very weak, and everyone has seen it, but no one has attested, and then everyone already has seen the block, then… It's not really clear what would be, because GetProposerHead for some people would be the parent, and GetProposerHead for some people would be the current block.

I mean, I don't particularly dislike this PR, it's just that I feel that we're going We're adding complexity and adding this attack, in which builders can increase the bid, knowing that that bid will never be chosen. So this provides a DOS that I don't see why would… why would we take it?

Justin Traglia: There's not really a denial of service. I mean, they're limited at 3 bits.

Potuz: No, I can just, like, I can open a ton of builders. Anyways, I know that none of this… none of this money is going to be a problem, because this bid will be very large, and… and I… I know that they're not going to be included.

Justin Traglia: I mean, you could do that now. It's just, it would be scaled by 3X with this PR.

Potuz: you cannot do this now if you only get one bid, and you're bidding on the head. Like, the right thing to do is to only accept bids that are for your head, so that bid is actually risking being included. If you accept bids for something that is not your head, then you're allowing traffic that might never be included.

Justin Traglia: Nico, you're unmuted. Do you want to say something?

Nico Flaig: Yeah, I still don't get why every node in the network should be forced to precompute the proposal head, like, that's not what we do today, right?

Potuz: Yeah, yeah, I agree. I agree that this is a downward, and instead, I think the simplest solution that is the best trade-off is to only propagate bits that are based on your current head. And in the case of an honest proposal, reorg, or whatever it is, let's just not ignore this case. I think it's safer than allowing traffic that might not be included. And yeah, for Prism, it would be even impossible to do the GetPROP… I think, I'm not sure. I think it would be very hard to do it with GetProposerHead. I would implement this with head.

Justin Traglia: Alright, let's discuss this more on Discord. I would like to spend the remaining 5 minutes discussing the other PR. Does that sound fine? Mark. The other one is, how should I say it? A bug that Sproul pointed out, pretty much. If there's missed slots, I believe the attestation rewards are incorrect. There was a debate between how to fix this, whether or not to add a loop and fork choice, which would pretty much bind, or, like, skip over the missing slots. And, whatever. I think POTUS was the one that suggested we instead just return the, The parent slot from process execution payload bid. And then propagate that to… process attestation.

And then, also to, I guess, get attestation participation flag indices. This is a bug fix, we should include it, or it's just whether or not we want to do it which way, with the loop or with this. I'm in slight preference towards doing this change, this PR, Just because I think it's a bit… More elegant, even though it changes more… functions. It does feel like the better fix, in my opinion. I'm… I'd be very curious to hear what others think. Yes, I can, sorry.

Any opinions? Thoughts? Yeah, I guess so. Alright, if there's no further feedback, I'll probably just merge this PR in, like, a day. So if… if you have feelings about this, please leave a review.

Potuz: I have one question, though. Will this change the spec test runner? Because I haven't implemented this, but my guess is if we implement this We will not be changing the signature of process operations? We will be just, like, saving that slot somewhere else.

Justin Traglia: Now that you mention it, yeah, I think this would actually change the test runner.

Potuz: Well, not in the spec itself. I wonder if we need to change our spec test runner to, like, so that process operation takes something different, or… Yeah, I don't know. I don't know how the spec test will look after this change. terence all.

Justin Traglia: Oh, it's just the first one to process attestation.

Terence Tsao: Yeah, I think we should change it.

Justin Traglia: Yeah.

Potuz: So for process attestation, sure, we need to have that slot, but for process operations, it's the one that bugs me. The ugly thing of this PR is that, is that it changes the signature of process operations when that SLOT is only needed in one of them.

Justin Traglia: I don't think we have process operation tests, we have individual operation tests.

Potuz: Then that's… then that's… that's perfect for us.

Justin Traglia: Yeah. I'll handle that, thank you for mentioning it. Okay, before the call's over, I'll make a PR with the idea that, potu said about the bits, and then from there we can judge it on Discord, and then please take some time to review. this other, PR, the second one. And we can merge that tomorrow, if all seems fine. Other than that, we are at time. Thank you guys so much for joining. Talk to you. And, sorry, talk to you later. For the first PR, can't we just have multiple builders? Yeah, we could, but… I don't know. Like, that's an option, too.

Barnabas Busa: And doesn't keep this back.

Potuz: I'll repeat the same, Barnabas, it doesn't solve the problem, so… I think we should limit traffic to things that can't be included. Even if you have multiple builders, you shouldn't be able to submit many bids. Because, unless you submit bits for the same head, that is the includeable one, and in that case, only your most valuable one would propagate anyways. So that's the beauty of filtering by head, in that there's only one bit that propagates. Otherwise, we have this global topic that can be dosed by anyone.

Justin Traglia: Yeah, I… I mostly agree. Alright, I'll make a PR. Let's see what it looks like. Bye, everyone.

Potuz: Bye-bye.

Dmitrii Shmatko: Bye.

Barnabas Busa: Justin, are you still here?

Justin Traglia: Yeah, I am. It won't.

Barnabas Busa: Let me stop.

Justin Traglia: Brying my screen.

Barnabas Busa: Can I just have a quick question?

Justin Traglia: What's up?

Barnabas Busa: Yeah, with the… with the second one, why do we want to fix this bug, actually? Wouldn't it make sense to just pay the Validator only if it is able to propose a block for the payload?

Justin Traglia: Well, I mean, we should fix this. I… I… I heard that argument before. I mean, yeah.

Barnabas Busa: Because, like, the chain…

Justin Traglia: Really. It's not for builders.

Barnabas Busa: Yeah.

Justin Traglia: It's not for proposers, it's for our testers.

Barnabas Busa: See if you're attesting to the wrong thing. Yeah, because.

Justin Traglia: I believe… actually, Ugh, I just don't remember. I thought it was a few attest. Er. Mmm. If there's a missed slot before your proposal, And you attest to that. none of the validators would… none of the attesters would be rewarded appropriately, or something along those lines. Like, it is… It's wrong.

Barnabas Busa: Okay.

Justin Traglia: And just, like, not rewarding them appropriately would be incorrect, in my opinion. And it's fairly simple to just fix. It was a mistake.

Barnabas Busa: Okay. Alright, send it to… Thanks.

Justin Traglia: Yep, will do. I'll wait 24 hours.

Barnabas Busa: Yep.

Justin Traglia: Yep. Alright, happy you're back, Barnabas, by the way.

Barnabas Busa: Yeah, thanks.

Justin Traglia: Yeah, just… alright.

Barnabas Busa: Bye-bye.

Justin Traglia: Bye.

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