FOCIL Breakout #45

Transcript

Justin Traglia: Hey, Jihoon, how's it going?

Jihoon Song: Justin, doing great. Can you hear me okay?

Justin Traglia: Yep, which is fine.

Jihoon Song: Okay.

Justin Florentine: What's up, censorship deniers?

Justin Traglia: Good morning, Justin.

Jihoon Song: And people are getting late, so let's wait for a few more minutes.

Alright, the remnants in, let's get started. Welcome, everyone, to FOCIL Breakout. 45. Today, we can discuss client updates and some spec discussions. So we haven't met… we haven't had much progress after Heze… devnet 2. Definitely was about. Quick slots, but still, let's start with client updates. Do any clients want to share some updates?

Marc Harvey-Hill: On Nethermind's side, we have implementations of, quick slots. And also the changes for heze-devnet-3.

Jihoon Song: That's a great tip.

Fabio Di Fabio: Hello, on the Besu's side, We are, a bit behind, since I had to… Refactor a bit the code in order to… a parcel dive test. And so, the quick slot… feature… Needs, to be implemented yet. I'm, working on it, but it's not yet ready, so… We could be… Fine if the slot time doesn't change from 12 seconds, otherwise we need to wait. Until this is implemented.

Jihoon Song: Gotcha. Thank you.

Rahul Barman: Update from the, Lighthouse side, most of our work is currently present in the, heze-devnet-3 trunk branch, and we are steadily emerging, those updates into Unstable as well.

Jihoon Song: Okay, great, any other clients? Geth/Erigon… Update from Prysm. Currently landing FOCIL stuff. and trunk branch, involved in devnet 2 and 3. Thanks for the update. And… yeah, let's move on to spec discussions. We have… some PRs. To discuss, and then we can move to FOCIL frame discussion.

First off, we have some… issue related to receiving bids at or after the IL deadline. Here are… The links to the… Rather than PRs. Yeah, Nico, do you wanna… Give us some intro.

Nico Flaig: Alright, yeah, so… the first one is the Validate and select bids on the inclusion list view at the deadline. So while reviewing our FOCIL implementation, I realized you can basically grief the proposer and builders. In the current design. Because the, proposer picks bids, that need to satisfy all the inclusion lists, whether they are timely or not, while, like, attesters only have, like, a subset that is timely. So… Basically, the first attack there is that a single member can grief by, releasing IL really late, and then If the proposer sees it, you invalidate all the bids that exist during bid selection. And even, like, a builder could use this as an advantage if they control a committee member.

by, like… because only their bid would be IL compliant. And all other builders didn't see the IL, right? If it's late, And then the second part of the PR is basically a builder. gossiping a very high bid early in the previous slot, basically before the IL deadline. And the current spec basically doesn't… enforce that you… it needs to be IL compliant. to be gossiped, so you can broadcast a very high bid that you know will not be selected by the proposer later, but it outcrowds all the other bids. So it's a way of griefing other bids. So basically, yeah, the changes just adding? one gossip check, which, says ignore bids before the IL due time in the previous slot.

And I guess the second part of this is that the proposer should also just consider the ILs that are timely. So you can, like, it enforces the same view as attesters, and also makes sure that builders, have the opportunity to see all the ILs when they broadcast their bids.

Jihoon Song: Yeah, thanks for the intro. Any questions or comments?

Justin Traglia: I was just gonna say… If these are, like, two options, I would prefer the second one, 5741. I, I think this is a more logical way of doing it, or a slightly better way of doing it.

Jihoon Song: Yeah, the way I view this is actually the 2 PRs handle different problems? the issue that I have with the second PR, which is 5741, is that it sets only timely to true, but the problem is that when an IL is sent close to the deadline. Some attesters might say EL might say it, while others don't. So, the proposer receives it after the deadline and not consider it It will lose some attesters' vote. Dope. I think… oh, they should be set up.

Nico Flaig: Wait, wait, wait. This is not about the proposer, though, right? Like, the proposer should always use a superset, like, based on all observed ILs, right? This is how you filter the bids you receive.

Jihoon Song: Is it just about builders? Yes, Bill.

Nico Flaig: Basically, with…

Jihoon Song: change.

Nico Flaig: Fits a builder, a proposer's supposed to pick during proposal, right?

Justin Traglia: Yeah.

Jihoon Song: Right, so builders were not gonna… Consider… untimely, but… not equivocating IL after this PR, is it correct?

Nico Flaig: I mean, the builder has the same incentive as a proposer. They want to include as many ILs as they can, right? Because you cannot be sure that you've seen all at the deadline, if there were, like, late ones.

Jihoon Song: I think I misunderstand something, like, what… what does it change with this only timely change in this PR?

Nico Flaig: So in my PR, right, the current spec… says a proposer should not pick bids that, don't satisfy their superset of ILs they've seen, right? So if you receive an IL even in the next slot, you should still consider it when you propose a block. That is, like, the current spec.

Jihoon Song: Well, this basically… You ignore ILs after the SLOT.

Nico Flaig: I mean, it doesn't matter after the slot, or… like, it can be really late in the slot, way later than the timely deadline, right?

Jihoon Song: Yeah, but it cannot pass the slot, technically, because the gossip-s gonna drop it.

Justin Traglia: But you still… Yeah, it doesn't really make a difference, versus, like, what Nico was saying.

Jihoon Song: Yeah, yeah, yeah.

Nico Flaig: The problem is mainly that there's, like, a race, That can happen.

Justin Traglia: For 5740, I'm not quite a fan of the language, like… should do their best to select a bid. Like, to me, it's just a bit ambiguous. And I'm not entirely sure how it would work in practice, like… Whereas 5741 is a clear… There's clear to me how it would work.

Nico Flaig: Yeah, I was talking with NC about this just now, or, like, before the call, a bit, and it's also not clear how the implementation would implement the other PR. I think it's an either-or, right? There's no middle ground.

Justin Traglia: That's the way I feel as well.

Jihoon Song: Yeah, do we have more comments?

Justin Florentine: Yeah, I felt the same on 5740. It really needs an explicit deadline or some sort of timing to make that decision.

Jihoon Song: anymore. Comments? Yeah, maybe preferably from CL devs. I just wanna double-check before… We decide to merge this in.

Nico Flaig: So is there, like, still the intent, as you noted, on the PR, to punish the proposer if… if a wrong bid is selected, or…

Jihoon Song: I mean, reorging the beacon block if it contains that inclusive bitlist.

Nico Flaig: Yeah, I mean, then it's a bit difficult, right? How do you pick the bid?

Jihoon Song: Yeah… I think we should have that change order. At least we need to discuss. Whether to have that change in the future, in the past, we… have this bitlist, I mean, having bitlist in fork choice, and… It kind of fizzled away, because it was not a super top priority, but… It's kinda… like, TBD, and I think we need to… Pleasure out. Sometime in the future. And… in terms of incentive, I think it is the right way to reorg block, because It aligns proposer's incentive to choose inclusive bit lists. And I think it also aligns builder's incentive more to consider ILs as many as they can. But currently, we are not using bitlists anywhere in the spec, just requiring… I mean, asking, kind of.

proposer to choose inclusive bit list. But… yeah. And this, incentive. our demand. It's also related to this attack, as he pointed out in the PR. So, yeah. I think we should consider it. I think we don't have to make a decision today. Yeah, Justine?

Justin Traglia: I… I don't know what I was gonna say. I was gonna say in 57… sorry, 5740. I'm also just opposed to making it non-mandatory. Like, it just feels like we're weakening. like, the value of ILs. If we do this. But maybe I'm misunderstanding something.

Jihoon Song: Perfect. but it's still… I mean, Not defending 5740, but even if he… change it to shoot, attesters. We're gonna vote for the head if it's not IL compliant, so… but I do agree that it is kind of weakening the purpose of IL. And, yeah, as Nico pointed out, I think we also need to consider how BitList will gonna play out in fork choice, so maybe we can Make a tentative decision to prefer 5741 today, and then see where it lands. Along with the bitlist in fork choice. Hi, this is Alan.

Nico Flaig: Yeah, I mean, my main concern, right, is my PR makes, lets more bids slip through, basically. So it would Like, once we change this, that the proposer also gets punished, then you might use a different strategy, how you select bids. But yeah, I'm not sure how you would prevent the griefing attacks that I pointed out while also, like, picking a superset of ILs, So yeah, I'm not sure how to solve that right now.

Jihoon Song: I see. Then just putting this… Super, super sad bit list aside, What do we think about… Considering bids only after this. when was it? IL deadline or something? Because the PR has two parts. One is about inclusive, at least, and the other part was about… Yeah, IL deadline. I mean… A secting bids after the IL deadline. Or…

Justin Traglia: Sorry, I'm just a bit confused. I thought Nico's PR only did this second part. We're in cotton. Is that what you're talking about?

Jihoon Song: I'm not following what the second part you're referring to, but what I want to say is that, you know, in the course PR, it changes P2P spec to consider bids only after the IL deadline. And… Yeah, I just want to ask, what do we think about this change? Because if… Spec changes related to this only timely thing is a bit unclear, then maybe we can agree on this. Bid propagation window first.

Nico Flaig: Right, so there are two parts, so one is when you… what bids you select when you have to propose, so at, like, at the start of the proposal slot, and the other one is on P2P, what bids do we let slip through on gossip in the previous slot? But I think you always have to evaluate the bids, on a frozen IL view, so… There's, like, a comment from NC. The other thing is, if you've seen all the 16 ILs, I guess you could allow bids earlier. Because you know there won't be any more, right?

Jihoon Song: Part of this to… Oslovano. Are they related to each other in some way?

Nico Flaig: I mean, the thing is, right, like, there's no point letting bids in your op pool and, like, outgrow other bids on P2P if you already know you might not pick it, right? Like, at least right now, the bids that are in our pool, we always can consider them during proposal, and you basically pick them by value, or like… it might be with, like, Boost or whatever, but… with this and FOCIL, right, you could have bids in your op pool that you cannot even pick, so…

Jihoon Song: Yeah, what do I want to say?

Nico Flaig: the second, like, griefing point.

Jihoon Song: Yeah, maybe we could split your PR into two PRs, like, one about… This bid propagation window, and the other about only timely, and maybe we can merge the, bid propagation window first, if it's… Clear, and if we agree that that's the solution that we want to have for the first type of attack, and that we can Circle back to the only timely thing with… more concrete. Suggestion for bitlist in fork choice. But yeah, it's just… We don't have to make any decision today, we can just discuss offline until we have more information.

Nico Flaig: So I think the P2P rule, is, like, the mandatory one from, like, the normal spec. You could even drop the validator node. But it's, if you get bids from external sources, right, like builder, API, Small for that case. So at least to me, I feel like they belong together, but we, I guess, could split it, if you like.

Jihoon Song: Okay. Yeah. Okay, I think we can just leave it as is, and then… See what's the right solution. Considering the bitlist in fork choice. Maybe we can discuss it in Devcon. So, yeah. the… Next PR that we want to discuss is… This one, which is also by Nico. Do you want to also give us some intro?

Nico Flaig: So that one I found during testing, which is that I noticed that Lodestar picks a IL unsatisfied payload as head in our current slot. And there was, like, this, anthropic scan that found the bug in the spec that I noticed my PR fixes as well. I'm just not sure… If it's like… Was it intended that we didn't consider the current slot, or… I'm just not… sure if my PR, it's, like, the ideal solution. But at least I think it is, but yeah, curious what others think.

Jihoon Song: Could you share what was the… Problem?

Nico Flaig: So basically, there's two problems. One is on bid selection in P2P. So, right, we have this, the check, which is, like, is_bid_compatible_with_head, like this one? Which basically only lets bids pass through that are compatible with your head. So, in the current spec. even if the payload doesn't satisfy the IL, we still pick it as head, and then… bids that build on empty, because they, like, the builder was bidding for empty, because it saw, like, okay, it's not IL compliant, the previous head, or the previous payload, right? Will not be propagated on P2P? And then the other thing is, when you… Prepare payload in the previous slot. Like the prepare ex… How's it called on the spec site?

So, at least in Lodestar, we prepare the payload in the previous slot, and if you pick the full, then… Should build on full doesn't have any check that's, checks, like, for the EL itself. So you basically prepare payload on full, but then at the start of the slot. You… this… this previous slot check runs, right? Where we check should extend payload, and that one returns false, because it's not IL satisfied. So at the start of the SLOT, you basically pick empty, so you prepare this, the pay… your payload on the wrong head, basically.

Jihoon Song: I see. It sounds like… We're gonna use more time to look over this problem, and… Discuss a solution, but still… Does any devs have any questions or comments? I guess it's…

Nico Flaig: Simple question, right, is should we return full as our head in the slot, even if the payload didn't satisfy the IL? I guess. The question, right?

Jihoon Song: Yeah.

Nico Flaig: It's… it also kind of applies to the EL, because we do, like, a new payload, right? And if the… then the EL says, like, oh, it's not compliant. And then the question is, should we still FCU it to the EL and tell it it's the head, or should we not do the FCU call?

Jihoon Song: I think we should not. I think there's some technical issue in the spec, I mean, subtle edge case in the spec that allows this. I'm not sure what's the best solution to this problem, but… Yeah. That's a good point.

Nico Flaig: Yeah, I guess with my… with this change, in the current slot and in the next slot. payload that doesn't satisfy the IL can never become our head, basically. But then, in the slot after that, right, if, like, attesters vote for it still, because your node didn't have the… has had a different IL view, for example, then you would still, Pick it as your head, right? Based on the attestation rate.

Jihoon Song: Yeah. Yeah, I would love to think more about this issue, and… Please also have some time to look into this and suggest solutions, or leave a comment, if any. Yeah, before we move to FOCIL and frames, does anyone have any PRs, or… Anything to discuss? Otherwise, I think we can move on. So… Previously, Marc proposed PRs to support FOCIL and frames. Thanks again for pushing this. This would help us move forward.

And based on their approach, I've opened to PR, Study Explorer, Another approach, there are… the links and the PRs in the chat. The main difference is that my PRs… has led the EL to pass ILs instead of IL transactions. So, previously, the main motivation was that Previously, the EL has to construct Membership, which is a data structure. That represents which IL transaction belongs to which IL. This was necessary because the EL needs to check profile 2 transactions up to some verified gas limits, but in my opinion, this is leakage, so instead. what we could do is passing ILs for your payload and FCU,

This way, the EL will do… The deduplication, and whatever checks and nits. The EL will return omission claims, which is same with Marc's original approach, and these claims will be passed via uPayload along with ILs, whereas is just the same. So, and passing ILs also taps… the Beacon event for builders. As far as I remember, there was an issue that Builders should be able to know which ILs they have to consider for their payloads building. And it was not super straightforward, because the event that builders are listening to emits bitlist, not ILs, so… This also kinda… Get to things that don't at once. We'll cover this again in L1 days in a week, and once we settle in some decision, I think we can target zero.

So, yeah, any questions or comments?

Nico Flaig: I'm surprised by the one comment you had, which is, like, the… payload attributes, we emit all the ILs, right? Already, that's appearance spec.

Jihoon Song: Not really. Maybe I'm… maybe I'm wrong, but… There we.

Nico Flaig: So the previous issue was with the bits, right? The inclusion list bits?

Jihoon Song: Yeah, yeah.

Nico Flaig: That we missed.

Jihoon Song: I'm… Do you recall what was said exactly?

Nico Flaig: So the problem was, right, like, the CL dedupes transactions, and then only, emits in the event and in the payload attributes also we pass to the local EL. We passed the deduped list. So, as a builder, or even, like, the local EL doesn't really know what ILs it satisfies, right, based on that. Because we are not emitting the raw ILs, like the 16.

Jihoon Song: I see.

Nico Flaig: So is the intent of the PR to pass, basically, all the 16 ILs without deduping on the CL side?

Jihoon Song: Oh, no, without deduplication. So, from a sales perspective. CL doesn't have to do byte-to-byte comparison for deduplication, so CL… Now doesn't have to care anything about transaction, so they just need to… receive ILs, and, you know, of course, they have to check equivocation, so on and so forth, and deadline stuff, committee stuff, of course, but that's all. So, they care about ILs, and they just pass it to EL, and then EL… EL we're gonna take care of IL transactions-related stuff. The downside of this is it will gonna cons… I think it was gonna consume more engine API bandwidth on average, because there would be some duplicated IL transactions, but the max size of this bandwidth consumption is still 128 kB.

And… based on the assumption that payload size… I mean, the size of payload at 20 mil gas limit would be… 3 megabytes. This max size, at the worst case, is around… 4.4%. of the max. payload size at 200 mil. But given that Given the fact that we were gonna increase gas limit over time. I think this trade-off is worth the make. By paying this cost, I think we can have… A better design abstraction, but… I really want to get some feedback, so we can have some robust design.

Marc Harvey-Hill: Yeah, I think, like, separating them makes sense, and it's just, like, A lot cleaner that way. And yeah, probably worth, like, the bandwidth trade-off as well, but I'll take a look at your PR.

Jihoon Song: Oh yeah, they're really great. I'm just curious, so we have Nethermind and ethrex prototype. for FOCIL-frame interaction, do they implement your PR?

Marc Harvey-Hill: Yeah, influence the PR, except, so I made some similar changes to, like, what you suggested in terms of separating the ILs. And I haven't updated the implementation yet, but, yeah, so they implement, like, an older version of the spec at the moment.

Jihoon Song: Okay, cool. It seems Mehdi also prefers this. Passing ILs approach.

Mehdi Aouadi: Yeah, I definitely prefer the abstraction of the profile tool validation.

Jihoon Song: Okay, yeah, looking forward to discuss this. And offline, in a week, if anyone attends Devcon. But, yeah, I'm happy to… Share that more context, or answer any questions. So, regarding the devnet schedule, once we figure out what kind of design we want to have for this FOCIL frame interaction. I think we can… Have the specs ready, and then… Yeah. carve the reliefs, and then try to launch hegota-devnet-0, probably… after Devcon.

Don't have a clear timeline, but yeah. I think this has higher priority. Gotcha. Yeah, to answer Mehdi's question in the chat, a FOCIL frame would be a target defined as 0 from my understanding. I'm not sure what else we want to put in there, but yeah, I guess that should be the one that we want to test. Mainly in hegota-devnet-0, but… The timeline and the exact scope of how we're gonna do in a zero is not set yet. to tap quickly.

previous agenda. As Nico suggested in the chat, But then we can get rid of inclusion list bits, and… Payload Attributes. Event… Yeah. It'd be… it'd be really nice, it'd be good. Have someone to modify the PR. And… yeah, actually, this is all the agenda we have for today. Before we wrap up, does anyone have any questions or comments? Just a little bit of housekeeping stuff, so, next breakout is… One week after Devcon. But… As people will be traveling, and probably not so much to talk about Right after Devcon. So, I'll suggest to push it back by a week, which is on the 17th of November.

How good does it sound, everyone? One thumbs up. 2 or 3. Thanks, everyone. So… Yeah, enjoy your travel, Nico. Alright, any last comments? Alright then, let's get the wrap in a week, if you plan to attend Devcon. Otherwise. Hope you have a great rest of your day, and… See you on the 17th. Thank you. Bye-bye.

Justin Traglia: Bye, everyone.

Mehdi Aouadi: It is nice.

Rahul Barman: A goo.

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