All Core Devs - Testing #100 (CL Breakout)

Transcript

Enrico Del Fante: Okay.

Justin Traglia: What is that Enrico?

Enrico Del Fante: Hey. I was talking to my daughter, sorry. She started unmuted.

Justin Traglia: I'm sorry. All good. Yeah, I realized that we're running a bit short on time, so I wanted to do this quickly. Okay, to get started, there's, I guess there's 15 of us in here. I wanted to remind everyone that we published the Beta 4 release, and that you should ensure your Hoodi Hoodi releases are compliant with that version because there is a breaking change. for an edge case. Nico, could you double… or sorry, could you confirm really quick? That PR is included in your Lodestar release, correct?

Nico Flaig: Yeah, yeah, we have all in. So we are passing beta 4.

Justin Traglia: Okay, awesome.

Nico Flaig: Also, there's a spec test. So if you don't pass it or if you forget to implement it, as long as you pin beta 4, you should fail spec test.

Justin Traglia: Yep, indeed. Okay, jumping into the next discussion item, Jihoon would like to discuss raising the inclusion list deadline from 8 seconds to 9 seconds. Can you talk about this one? Some Jihoon.

Jihoon Song: Yeah, thank you, Justin. So, it's a proposal to set the IL deadline to 9 seconds into the SLOT. We're not talking about Tesla here, so slot duration is 12 seconds. The main motivation is to give more time to build and broadcast ILs. So I look into some data, and Benchmark Core says, the worst case time it takes to process a payload with 200 mil. Was an average of 1.4 seconds. A median of 1.5 seconds, and a maximum of 4.8 seconds, so… When a node receives a payload at 6 seconds, in the worst case, it could be tied to produce a fresh IL. So… but it is still a tentative deadline, but I believe it's better to put it at 9 instead of 8.

And… I think this is the right way to do it at the moment, but of course, we can settle in. Once we have main data later, and if we have quick slots, SFI. Then, we can also… I take the factor into account, and then… yeah. find a better number later. But for now, I'll suggest to put it at 9. And… I'd like to get some feedback on this. It is not a must, but… The point is, we want to have IL be more effective. Effective could be defined as it is. We expect IL to have transactions that were not included in payloads before. And… Some ELs might not execute payload. when they produce IL, they might just exclude transactions in a payload, optimistically believing that they will be correct and produce better IL, but yeah.

Executing payload before producing ILs could give you a… you know, a good guarantee that your IL will have a fresher status. Nico and Barnabé.

Nico Flaig: So my main concern with this is that you give less time to the proposer, right, to prepare the payload. So do we already know how, well ELs work by, adjusting their payload, quickly?

Jihoon Song: Yeah, I also look into that data from Sepolia Shadow Fork 1, although this is a bit heuristic, so it is not Affirmative as much as what BenchmarkCore says, but If you look into the PR, I also… let me also share the link to the gist that I summarized the data set. So, the time to produce Payload. was… like, sub-second, basically. Of course, it depends on what kind of appliance you use, so on and so forth, but my understanding is… my reasoning is that it takes less time, much less time, to produce payload than processing a payload. Of course, in the worst case.

NC: Looks like it's only up to 150 million gas. And… it looks like it's also not measuring the publication timeline. into these numbers.

Jihoon Song: I couldn't get a data. of 200 mil block building. So, of course. So again, this is not a final deadline, it's a tentative deadline. But yeah.

Dustin Brody: a meta point around this, I mean, as far as changing these parameters, and this is not for or against 8 or 9 seconds, or anything in particular, but let's say derived from a certain… experience. in Amsterdam with a similar thing where one of the, was a payload to VPS, I believe, was changed from 7 ,500 to 5 ,000. There was a certain, certain client which kept shipping an old version of this, of this constant in their shipping releases. Nimbus VC compares them, the, like. all these constants, which it should, that's not the problem, per se, and I would count as essentially a bug in this other client that they kept shipping an old version of this constant, and this is always the risk of changing. I mean, look, if you want to change the number, change them as soon as possible, sure, but I just want to say that

my… the angle I'll have here is, can we please, this time, get people to actually, in their shipping branches, I do not care what's in their trunk branches, in their shipping branches, ship the current numbers. Thanks.

Jihoon Song: Yeah, thank you. But… Yeah, we should make sure that we have… I mean, we should make sure clients have the right parameter set. And. Yeah, so. Can I get some buy-in to merge this PR? Or if anyone's rejected, opposed to this PR, that's also fine. I think we… Just need to make a decision on what to do with this proposal. Regarding SLOT rep… Yeah, go ahead.

Justin Traglia: No, it's fine, Nico. I think you're gonna answer the same thing.

Jihoon Song: Yeah, regarding SLOT reduction to 10 seconds. Currently, we just use all the same BPS, so… It will be set at the same time of 75% of 10 seconds, which is 7.5 seconds into the slot. And this is also just tentative, you know, just like all the other sub-slot deadlines.

Justin Traglia: I'm fine with raising it to 9 seconds, or 75% of the slot duration, Jihoon.

Jihoon Song: Okay.

Justin Traglia: Is it… is there anyone that's against this?

Nico Flaig: I mean, I'm having a hard time to reason about this right now. Seems both fine to me. And we can maybe tweak it later if Jun thinks 9 is better, or slightly better. I also think 8 is fine. We will see, like, how we build local payloads, whether 9 is an issue.

Barnabas Busa: One thing I also is if we do 10 seconds and then that's gonna be 7.5 seconds. So like do we. Want to adjust this once, or do we want to keep adjusting it? As you keep merging in. Different ideas, like…

Jihoon Song: In my mind, we can… Once we start testing SLOT reduction. We were gonna see where we want to put deadlines. In 10 seconds of SLOT duration. And then, we can also decide where to put IL deadline. So, I don't think we're gonna be, like, changing deadlines here and there. So, after we move to 10 seconds SLOT duration, this would stay at 7.5 seconds. But once we figure out what numbers we want to go with. We can adjust that. And another argument that one can make to push this deadline toward the end of the slot a bit is that you can maybe collect more PTC votes, but…

This is something that I don't really like, but yeah, it is not super wrong.

Justin Traglia: Alright. I think we should move on to another topic.

Nico Flaig: Yeah, one comment on what Dustin mentioned. So I think what clients should do with these future configs is only evaluate them if the fork is actually scheduled. So in the case that Dustin mentioned for Gloas, we shouldn't even validate the payload due deadline if Gloas isn't even scheduled in the client config. That's at least what Lodestar does. And that way we also prevent this issue or avoid it where like Configs that aren't basically used are not validated. Because, yes, this shouldn't affect mainnet users and cause interop issues, and we had at least two users that had this issue. Actually, the other way around, though, because Lodestar was too fast, and other clients lagged behind and validated the config strictly, and

I had to add two workarounds for this. Just to patch it on our end. But I think it's completely unnecessary to. validate configs that are not used. I don't see a reason to do that.

Justin Traglia: I totally agree.

Jihoon Song: Yeah, so regarding this PR, if I were to go this quickly, so we had like two to three. Support and no opposition, so… Yeah. Can I say that we can merge this in, and then move on?

Justin Traglia: Yeah, let's just do that. Yeah, okay.

Jihoon Song: Thank you. Yeah.

Justin Traglia: Okay. Okay, the next topic is, about quick slots, EIP8198. I think in the previous… Okay. call. I don't know what to call it. We decided to just to Try to merge this as soon as we can, and make a Beta 5 release June.

Jihoon Song: Yeah, so as we decided in the… previous room. We can merge this PR in, I'm gonna merge this after this call, and then… once we have this… have those two PRs, we can kind of release today, unless we…

Justin Traglia: There are testing issues.

Jihoon Song: arts.

Justin Traglia: Which I think Nico is about to talk about.

Jihoon Song: Okay, yeah. Nico?

Nico Flaig: Yeah, I have one complaint about the current state of the PR, which is we aren't actually testing the Heze slot duration change. So even if you don't implement all the reward computation in the client, the spec tests pass. Because the tests just run with 12 seconds. And then we would yeah.

Jihoon Song: We didn't add any tests for… you know, this feature EIPs, like the other one, and then quick slots, because we wanted to maintain It's just for the sake of maintenance issue, but one… as we decided to put this in, we should add more tests. And we can have it before we cut a release, if you want. Okay.

Nico Flaig: problem.

Jihoon Song: I.

Nico Flaig: Right now is, like, clients can pass Beta 5 spec tests, with implementing quick slots, but even if they don't. implement any STF changes, and then when you run it actually on Kurtosis and you change the slot time, then you have a consensus split if clients didn't implement it correctly.

Barnabas Busa: Well, but that's what we said that for the next devnet, this is acceptable. Because we're just gonna stick to 12 seconds, and then we can have the following devnet. require STF changes and the actual shorter stuff.

Jihoon Song: But if clients wanna… Make sure their implementation is correct. I think we should provide some spec tests. I think that's what Nico is asking for.

Barnabas Busa: Yeah, of course.

Jihoon Song: Yeah. So… Yeah, I can add those tests for QuickSlots, and we can include it. Before we make a release. And… How does it sound?

Justin Traglia: That sounds fine to me. There's no immediate rush to get this out. Maybe target, like, Thursday or something? Would that be fine?

Jihoon Song: Yeah, sounds good to me.

Justin Traglia: And, we should also take advantage of our champion Barnabe for this as well.

Barnabe Monnot: I'm… I'm around, just let me know.

Justin Traglia: Cool, thank you. Okay, we only have a couple minutes left. Luca, would you like to discuss that new Beacon API endpoint?

Luca | Vero: Yeah, sure. So just a quick recap, it's the Beacon API endpoint that would allow validator clients to supply their own bids. I added some motivation since last week to the PR. Let me just Bunk. This one. Yeah, I haven't received much feedback. There's one new comment since last week. I would appreciate if some more people could take a look at it. Yeah. Do you want me to? Recap the last comment as well, Justin, or should we just leave it?

Justin Traglia: Up to you. We have time, we can go over by a minute or two if you want.

Luca | Vero: Okay. So what I posted, is about multi-node setups and how this API endpoint helps them. Basically, today. All of the bid selection happens in MEV Boost or Commit Boost, so it's a small piece of the stack. which is relatively easy to keep track of and monitor, but with Gloas, This bid selection will probably move into the Beacon out a lot of times. And when you use a multi-node setup like we do, that gets a bit complicated. Because, well, in our setup, our validator client talks to 5 different CL clients, and if every of those clients handles bid selections a little bit differently. It's just a lot harder to… Investigate issues and keep track of and monitor, alert on.

So that's one of the reasons it would be useful for bid selection to Move into the validator client if desired, so it's just optional. So that's the whole monitoring aspect of it, and the other aspect of it is, when it comes to block production, again, when the validator client talks to 5 different CL clients. They each return a block. And they may each return a block that contains a different bid. So… You're guaranteed that 4 out of 5 of those CL clients are not gonna include the optimal bid. When they each do their own thing. So for that reason, it would be more useful for the validator client to just give them a bid to include, and then they each return a block with the exact same bid.

Yeah, that's it from my side. Any quick comments before we wrap up?

Justin Traglia: Okay, clients. Yeah, please take a look. Don't. Is there a thread on Discord about this?

Luca | Vero: There is, yeah, in the CL APIs channel, there's a thread. Yeah, and… Yeah, this is the last, Beacon API for Gloas.

Justin Traglia: Cool. I'll post a reminder in the… Interop channel, or something, in just a minute. But okay, thank you so much for the update, and Talk to you guys, on Thursday. Bye, everyone.

Barnabas Busa: Bye-bye.

Jihoon Song: Thank you.

Nico Flaig: Yeah.

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