All Core Devs - Testing #90 (CL Breakout)

Transcript

Justin Traglia: Hello again. One second, we'll get started. Or… maybe, like, 30 seconds, actually. Okay, let's jump into it, I guess. Nico, would you like to lead the discussion on the open questions around specs for direct builders? I think there were the three PRs that you listed in your comment.

Nico Flaig: Yeah, so maybe even Jason can do that, but just want to point out it's not only for direct builders, so it's also just bringing all the MeV boost logic into clients, so even without direct builders, you still have the option for min build and boost factor for, like, P2P builds.

Justin Traglia: Okay.

Nico Flaig: But yeah, do you want to talk about it, Jason, or should I? I think you know it a bit better, so…

Jason Vranek: Well, maybe I can give just a big… or, like, an overview, and then you have, kind of, the open questions, because as of the last ones, I'm not too opinionated. But yeah, so there's kind of 3 PRs here, starting from the bottom, like the Key Manager API, Now that the Beacon node's going to be doing a lot of the auctioning logic, you have to do all these configurations around, peer-to-peer bids, direct bids, and who you can talk to, and it starts to look like this N by M matrix, where each key could potentially have different preferences for different builders, and so the motivation of the Key Manager API was to make it programmatic, to, yeah, configure your client, so you don't have to…

Deal with these, really error-prone large configs. And that sort of starts to flow the necessary data we need into the Beacon API, so there's this produce block before endpoint. And, we basically need to send enough information from the Validator client to the Beacon node to be able to facilitate the auction and fan out these requests to the… builder API endpoints. And then, once you get all the bids, you need to, you know, run the auction yourself, and there's, like, these… there's a min bid, there's a builder-boost factor, there's also this max execution payment value that constrains the builder API trusted bids. And yeah, so finally, at the rest… top of the stack, there's the 165 is the PR to update.

the builder specs, and I'd say this one has probably changed the least. It's mostly trying to clarify things, and get it more, up to, sort of, standard with the other PRs, after What Brath had left. So, I guess with that, there's… there's some open questions. I guess I'll let Nico take the…

Nico Flaig: Yeah, so, in the current shape, or the current state, we still support Well, let me quickly say how it… I think it should work. So, we have a global parameter today, right, with the boost factor for builders, or basically you can de-boost the builder block, which is, like, how we use it on mainnet. This is global, so it's applied to all the builder blocks, in a sense, because, I mean, MEV Boost just gives you one, but it already selects the highest one, or Commit Boost, or whatever sidecar. Now with clause, we could apply this to the builder API, which we already, like, the current spec does this. And there was also the question if we want this for P2P builders too, so bits you get over P2P.

The problem there was that the current P2P rules don't really allow this, so neither min-bit nor boost factor, work properly. Because on P2P, we, like, other nodes in the network will not propagate or consider these values, because they are local only, so the outcome is kind of random, based on how bits are propagated on the network. And, adding this for P2P bits, the per-builder config adds some complexity, And I think mostly from configuration side, it's not that nice. So just curious if people have strong opinions to keep it… keep this possibility to boost a specific P2P builder.

Justin Traglia: For simplicity, I don't think that we should have any builder… sorry, any boost for P2P bits. Just my opinion.

Nico Flaig: Oh, we still have that, by the way, but it's a global value. Not… not specific for… by builder index or pub key.

Justin Traglia: I mean, I should look into that. I should… we should… we could consider removing it, I think, for P2P bits, then. I… I mean, I… I think there should be a… you should be able to compare your local payload to a P2P bid directly, and only go with the local if it's one way. Or greater. And value.

Nico Flaig: Oh yeah, but that would remove stuff we can do today, because today we say we boost the local payload by 10% by default, I think many clients do this, so I think this should still be done. And this is simple, the complex part is if you want to do this per build or on P2P.

Justin Traglia: Okay, how do other clients feel? Okay, there aren't really any thoughts.

Jason Vranek: Or, just to answer your question, Justin, so this is, like. We have a global, min bid and builder-boost. for the peer-to-peer bids, and then we also have it where you can configure it per builder. And so I think there's a decision to cut per builder, there's also the discussion to cut global, which I don't think anyone wants to do, and then there's the discussion to, like, I guess, remove builder-boost… From the global, because it could potentially not be useful with the consensus rules for bids.

Nico Flaig: Now wait, why is the global one not useful?

Jason Vranek: Or wasn't the idea, like, you don't have control over what bids end up…

Nico Flaig: Oh yeah, that is the per builder, right? Like, even if you currently would say you 1000x boost some specific builder's bit, that one might never reach your node, because on P2P, we only propagate the highest bid based on, like, the actual bit.value, not, like, some boosted factor, right? So that's just the weirdness of the P2P bit boosting, or even min-bit, it just doesn't work, deterministically. So I think even if a user sets this, it's like a random outcome, which I don't like.

Justin Traglia: Okay, so where do we go from here for these PRs? What are you guys, requesting? Reviews? Or… do we need to make any decisions here?

Nico Flaig: I mean, that would be nice if we can decide on that one, because then I think the PRs are mostly in a good shape to review them. Because, right, Jason, right now it adds this option to boost and minbid per P2P builder.

Jason Vranek: Yeah, it's currently in the specs, I'm happy to, you know, take them out.

Justin Traglia: Is there anyone here that wants per- builder P2P? That boosting. Eitan says, I don't want this. I think Nico's… Doesn't want them either. Nico doesn't want them either. And then… Bot is the first is vote to Nico and Terrence. So, Jason, I think we should just take him out.

Nico Flaig: Yeah, I mean, it just doesn't work technically in a proper way, so… I think it's just bad to have such a design.

Justin Traglia: Makes sense. Are there any other open questions that we need to answer here? Or should answer?

Nico Flaig: I think we can do it async. I guess the ask would be, once the PRs… I think once Jason applies these updates, it would be good to just have people look at it, see if they… if, like, something they want to have is missing, like some config option, or whatever, like, just to get more feedback. There was, like, one… Sorry, go ahead.

Justin Traglia: I'm sorry, do we need to merge the PR before this is implemented in clients? For, like, a DevNet 8. Or could we wait for them to implement it, and let's test it, and then we agree to merge the PR?

Nico Flaig: I mean, does any client besides Lodestar run spec tests on the API? If the answer is no, then there's zero reason to merge this. You can allow more feedback.

Justin Traglia: Yeah, I mean, if it were up to me, I feel like we should have more clients implement this before merging it. Otis. Potus, are you fine with waiting to merge the PRs until, Client teams have implemented.

Potuz: We're still on the APIs, right?

Justin Traglia: Yeah, we are.

Potuz: I think it's fine, as long as we sort of, like. At least signal that this is… the current status is the right one or not. I was the one that was suggesting pair builder, so… and I'm fine with the removing the per builder. on the P2P side, if the people that are actually writing the PRs think that it's best. If we signal that it's fine now, we start implementing it, then we agree on merging. As they are.

Justin Traglia: Assuming that the implementations go well, and it works on DevNet? Yeah, sure.

Potuz: Of course.

Justin Traglia: Okay, I think… so the action items are JSON, or JSON removes the P2P bid-boosting config. And then, from then it… from there, it should be fine, right? Like, that's what we believe is, Good to be implemented, Nico? Yep. Okay, so then clients will implement that, version of the PRs, or PR. And then after there's a few implementations, we'll merge the PR. Does that sound fine for everyone? Alright. We have 5 minutes left. Let's move on to the next breakout item. There was a question in Discord about, This check being changed from ignore to reject. I believe it was Nico that mentioned, or like, that said that it doesn't make sense for it to be an ignore.

I believe I agree, there is not a valid Like, how should I say it? It's invalid for a builder to submit a bid for A balance, or sorry, with a great… a bid value greater than their balance. How do other clients feel about this? Cotus?

Potuz: I disagree, and the reason is that we should not force clients to, use a state that is not head to validate things. So this is not about what the builder sends, it's about what my peer is forwarding me. And… on most objects, we don't require the peer to have a specific state to validate the object. To validate this bid, you need to have a specific state that most clients might not need to have it. If it's the head state, then it's fine. And this is the reason why I think this was an ignore early on, because we're assuming that clients will validate the bid with the head state. And if the head state is not the right state to validate it, then they might get a different answer than what you would get from the right state.

We don't want to spend resources on this. So if we move to a reject, what I think is going to happen is that at least present will just ignore most of the bids that come for anything that is not head, which means that we just removed what the feature of this PR was adding, which is allowing for multiple bids. Definitely, Prism will not validate anything that is not built on head.

Justin Traglia: Nico, would you like to respond to that?

Nico Flaig: Yeah, I mean, in my opinion, this is still a recheck, because you can always guarantee that you use the right state. It's not timing-dependent, or not dependent on another message. So not, like… So, for example, can't Prism just say, if it doesn't match your head, you ignore it anyway?

Potuz: Yes, which is the reason why I'm saying that we lose functionality, because instead of forwarding this bid that we wrote a specific PR to allow those…

Nico Flaig: Ignore it anyway, right? In any case, you would ignore it.

Potuz: No, that's the point. If I… with my head state, I see that the balance is good, I will just forward it.

Nico Flaig: Oh, okay, yeah, yeah.

Potuz: But now, with your request of saying, no, I might be rejected, then I'm not going to forward anything, I'm just going to ignore those bits. And we lost function… we lost functionality, and we risk downscoring just for this stupid gossip path.

Nico Flaig: Yeah, I think that is good rational to keep it ignored, I would say.

Justin Traglia: Yeah, it makes sense to me as well. Okay. Should we just keep it as is, then? Or does anyone else have feelings? Alright, I mean, we just have one minute left, but Nico, would you like to discuss your PR on Epoch boundaries, or would you like to do it another time?

Nico Flaig: I can quickly… I mean, it's related a bit to this, so we noticed on the definet that we are kind of getting DOSED by bits at the epoch boundary, so we see a lot of the time that we do two epoch transitions, and that is because we get a bit for our parent. So that's why I added this to Lodestar. I think it's not good to have bits force us to do two epoch transitions. So I'm just wondering, is that something… I mean, this is a bit conflicting with the Lighthouse Epoch Boundary reorg. And there's a PR from potuz that even, allows this on the spec level.

Potuz: I think these are not contradictory, right? So, it's fine, if you don't have this data and you can't validate it, then it's fine, you just don't, and you ignore. But we are also producing… we will be producing those bids, and we… we are also reorging those blocks. And I think Prism will have it. If the last block came late, Prism will have this in the cache. So we would validate those bids anyways. I think it's fine for Lodestar to ignore those. I think we should keep in the spec that, the simplification of just not caring about the epoch boundary.

Nico Flaig: Yeah, I think I would be fine with that.

Justin Traglia: So I could be clear, so, we should remove that check, like your PR does.

Potuz: Right, so my PR… my PR just makes explicit something that I think both Lighthouse and Prism are doing now on Mainnet.

Justin Traglia: Okay. Could you, provide your rationale in that PR? It's currently empty.

Potuz: Oh, but it's… oh, yeah, sure, I can… I can add it. It's just the fact that the look-ahead already removed the… I mean, this check is called, something about the shuffling being stable, and the shuffling is stable because of the look-ahead.

Justin Traglia: I thought it was an epoch boundary.

Potuz: Yeah, but the epoch boundary is because of this. So the name of the constant was, isShufflingStable?

Justin Traglia: Yeah, okay. Okay, anyway, yeah, thanks. Just, like, a single paragraph. Concise. Something that, we can… Understand. Okay, anything else before we end this breakout?

Bosul Mun: Hi!

Justin Traglia: Hey. Oh, I'm sorry, did you say hey or bye? Alright.

Potuz: In Bosul was saying, oh, she has a rice…

Justin Traglia: Go for.

Bosul Mun: Yay. So, since we are short on time, I will just briefly mention this now, and… Suggest that we… continue this discussion asynchronously. So, at the last ACD meeting, we discussed making this per-spool Pool Engine API mandatory for the Glamster .NET 8. And Lighthouse team raised some concerns about how these APIs are designed, so we agreed to revisit this topic today. there has not been a counter-proposal yet, and her client teams have already implemented the current proposal, and I think the general view is that we… You should pros… proceed with… with this if… Unless other client team has, like, significant object… objections. So, please take a look and share your feedback asynchronously for me… to me.

Yes. Thank you!

Justin Traglia: Right. Thank you, and thank you everyone else, for joining. Alright.

Mikhail Kalinin: I think so. Bye.

Potuz: Bye-bye.

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