FOCIL Breakout #40

FOCIL Breakout · 18 Aug 2026 · 29:43

FOCIL Breakout #40, held on 18 August 2026. FOCIL, or fork-choice enforced inclusion lists under EIP-7805, is a proposal to make it harder for block builders to censor transactions. Besu, ethrex, Nethermind and Teku were all rebasing on glamsterdam-devnet-8, and Lighthouse had its inclusion list store and gossip and validator client work in progress.

Speakers

Topics

From FOCIL Breakout, hosted by Ethereum Foundation.

Transcript

Justin Traglia: Good morning, Jihoon.

Jihoon Song: Hey Joe Stan, how's it going?

Justin Traglia: It's it going? Just waking up. How about you?

Jihoon Song: I'm doing great. Looking into… I got EIPs.

Justin Traglia: Very nice. How many are you through with?

Jihoon Song: I just skimmed most of it. But I wanna look into till… I'm gonna look into till… decoupled Consensus, because… I think we're gonna… change Consensus layer quite a bit, and it will gonna affect my… preferences.

Justin Traglia: Okay. My computer, I understand. And yeah, we can chat about that more later.

Jihoon Song: Yep. Yep.

Justin Traglia: Good morning, Barnabas. And everyone else.

Jihoon Song: Alright, I think we can kick it off. Hello everyone, welcome to FOCIL Breakout. Orkye. Since we have some development progress. So, shall we start with client updates?

Fabio Di Fabio: Okay, I can jump in. I'm currently, porting Besu to Glamsterdam DevNet 8. That's done, actually, and I am… Implementing the latest. Changes to the spec. to the Get Inclusion list, for choice, and so on. I think… Oh. Maybe one day or two, that we're low. Be able to… To be ready for… Glamsterdam DevNet 8. Based on Glamsterdam.

Jihoon Song: Great, thanks for your update. It drags also… It's a regulatory based on Collab DevNet 8, Nico, do you want to share cluster updates?

Nico Flaig: Yeah, I was just checking if NC was here, but looks like he's not. So, I mean, not much from what he already shared, so he rebased our, FOCIL changes on DefNet 8. We have now this on the FOCIL DEFNet 0 branch. Yeah, I haven't looked at the div, but CIA looks good. And yeah, it should be what we had before. I'm not sure if we have the latest spec changes in. That should be good enough to interop, I think.

Jihoon Song: Marc doing me a definite 8?

Marc Harvey-Hill: Yeah.

Jihoon Song: I see. Is Teku on DevNet 8 already?

Mehdi Aouadi: Yep, we're on DevNet 8, and we're working on a DevNet Zero branch for FOCIL.

Jihoon Song: Right. The dependent route changes will… Let me think… Probably not. No.

Nico Flaig: Doesn't it change the container? Yeah.

Jihoon Song: Yeah, it changes containers, so… yeah, you're right. Justin, did we already release Alpha 14?

Justin Traglia: No, we didn't. The ACDT client said that they didn't really need it, but we can still release it for FOCIL if we want.

Barnabas Busa: Shouldn't you do, like, beta zero, or something like that?

Justin Traglia: Typically, or sorry, not typically, but I want to wait, like, two and a half weeks before the first, real testnet. To release Beta Zero. But I mean, it doesn't really matter. Soon.

Jihoon Song: Okay, so… Oh. But one with the release is I want to merge the dependent route changes PR, and then make a RFA 14 release, so that the clients can work on top of it. Because ANSI said that low 3 is based on All413, but not anything from 14. Yeah, we can discuss it later, in the spec update, so… Yeah, it seems that we… covered all clients here, so I think we can move on.

Cristian Conache: Sorry. Yeah, go ahead. Yeah, I can… I can provide a short update for Lighthouse. So I'm Christian, I'm part of Protocol Fellowship, and I'm working on FOCIL for Lighthouse, with Tragul, also part of EPF. So, we… we just laid out the groundwork for… for it for now. Our implementation is not ready for DevNet Zero. We have, some work, ready for review there on the inclusion list store, not yet in line with the keys change. And, some other work, covering the gossip layer, basically the inclusion list verification, and also the Validator client side for inclusion list publishing. So, Yeah, that's, pretty much it on the Lighthouse side.

Jihoon Song: Great, thanks for sharing, and let us know if you have more updates or any questions. Let's move on to the spec updates. Let me start with… the EL side, so… Ivan from ethrex opened the PR that fixes several issues on failing tasks. It's marched, and now it's rebased on top of Amsterdam. But the execution spec hasn't reflected the latest engine APIs, like Payload Status V2, so I'm gonna discuss this with still tomorrow, so that we can figure out… How to go about this. And actually, that's all for the EL side. Do we have any comments before moving to CL?

Barnabas Busa: I don't see any of the FOCIL tests on Hive. Is this supposed to be running already?

Jihoon Song: We do already have some hype tests. We might miss in some etch case. Test cases, but… Side it. Yeah, I can also check with this. Tomorrow, and then get back to you later. Yeah. Any other comments? Great, I think we can move on. On the sales side, we have two PRs. One is… 55, 12… Opened by ANZ, SPR, groups, including lists, and timeliness.

Devs were supportive, so it was merged. The other one is… 55, 45, I'm sorry, 44. It changes the keys in the ELT store from ILT committee root to a pair of SLOT and dependent route. It seems people are in favor of this idea, but I'd like to have some feedback on the function parameter. the bitlist functions need to know IL committee, so they… take state as a parameter, but this state is only for calculating the IL committee, so it's not desirable. Other ideas are… Putting the committee in the store, or passing the committee as a parameter instead of state. I'd like to ask… which way… Do we want to go?

Nico Flaig: So what about resolving the state inside the function? Because you already have it in Fortress, right? Just need to load the RED state.

Jihoon Song: Yeah, that's also possible, but then we need to pass the fork choice to our to this… BitList functions, which is an inclusive list store.

Justin Traglia: Yeah, that is a little awkward. I don't have any strong feelings on this, by the way. Whatever you guys think is best.

Nico Flaig: Yeah, I don't know right now, didn't really look into detail into the PR, so… I think E10 had some opinion. He's not in the corn, yeah.

Jihoon Song: Yeah, he didn't wanna insisted. just to calculate IELTS tour… sorry, IELT committee, from my understanding. I also agree with it, because… It's not really used elsewhere. That's why I removed it from, Other functions, like, getting closureless transactions. But there's bit listing, you need to know The index in the committee. Yeah, we can also discuss this in async.

I think this is the last PR. Before making the… Relates for FOCIL definite zero.

Justin Traglia: What do you think about defining? Sorry, the key as a variable, I forget what it was exactly. Slot independent root. As a key variable.

Jihoon Song: Excellent.

Justin Traglia: You… you decided not to do that for some reason, for those other two functions?

Jihoon Song: Yeah, it's just because… The one that we created, the key variable as a lengthy Access list, but slot and dependent road is, it's just, simple enough, so just not sure about… what it exactly improves, so… I'm not strongly opinionated on either way, but just…

Justin Traglia: I still think it would look nice to have a key variable, at least for consistency. It would be… I mean, I get that it's, like, not really necessary.

Jihoon Song: Yeah, I can edit. Can I ask your opinion on this? Entry suffix.

Justin Traglia: Which one is that?

Jihoon Song: like, in Clutterly's entry.

Justin Traglia: Oh, I see. I mean, technically, I would do… inclusion lists entry. His inclusion… inclusion list entry. Seems as if it's a single inclusion list, which is not.

Jihoon Song: What about in… in the store level? Do you want to be included list entries, or just included lists?

Justin Traglia: I mean, if it were me, I'd probably do inclusion list entries… list entries. But it's a bit of a mouthful. It is a bit confusing, though. The field name would be inclusion list, but it's not actually an inclusion list type.

Jihoon Song: If you were to go with this entry suffix. Do you… do you think it still improves? read the.

Justin Traglia: Absolutely.

Jihoon Song: Yeah, go ahead.

Justin Traglia: Actually, wait, I might be incorrect. I don't know. It's… an inclusion list entry contains one inclusion list, correct?

Jihoon Song: Yes, one inclination is timeliness.

Justin Traglia: So, inclusion lists… Oh, goodness gracious. I mean, I'd probably be fine with just keeping it as inclusion list. Like, like you have it now.

Jihoon Song: I see.

Justin Traglia: For the for loop. Like, it helps readability, sort of, because you can say inclusion list. Signature. But I understand what Eitan is saying, that it… it is a bit confusing.

Jihoon Song: Yeah, he does.

Justin Traglia: What was your other question? I'm sorry.

Jihoon Song: My question is. if we were to put this entry suffix, then I think it makes sense to put this suffix elsewhere as well. Like, inclusionist entries and equivocators in the store. But then it just makes things verbose, and then it kind of neutralized the benefit of grouping inclusions and timeliness.

Justin Traglia: Yep. Okay, my opinion's changed. I mean, I would just keep it simple, like you're sort of suggesting at the moment. And just do, like, inclusion list. For the variable name.

Jihoon Song: Gotcha Okay, then I'm gonna just keep it as is, and… Some more people come in later, and people want to change it to something else, then we can make a PR.

Nico Flaig: So regarding… I'm sorry, yeah. I just wanted to follow up on the state question, right? So the function is this one, right? Get inclusionist bits?

Jihoon Song: Yes.

Nico Flaig: Because that one, or… oh, it's, I see. No, I got that confused. It's inclusion list, not Fortress store, yeah. Yeah, I mean, I always kind of dislike this state as a parameter, because… You always have to look at the, like, caller side, what state it actually is. So, I think from a spec perspective, it's nicer if we can just have it resolved inside the function, or, like, be a bit more explicit about what the state is. Because I guess here in that example, you only need the state for the… the shuffling, right? You don't need a head state or something like this.

Jihoon Song: Then, the question is, how do we resolve it inside the function?

Nico Flaig: Yeah, I mean, right now, you can't write, with the inclusion list, so… I mean, the other idea you said was passing the committee directly, maybe?

Jihoon Song: Yeah, because the color side… the caller who calls this getting collateralist bits, or… The other one is… is fetalizing collusive or something, they will… gonna have the right state, so they can always calculate IL committee, and then just pass it, which is technically… basically achieves the same. The other idea would be… passing fork choice store. So that we can resolve the right state inside the function, but this is… I don't know, it looks like over-engineering. And the consensus idea is putting in the committee in the store. Which I feel like… Somewhat implementation leakage.

Nico Flaig: Yeah, I feel like on the implementation side, it's anyway gonna look a bit different, so… yeah. It's just… Matter of how to properly express this on the spec side?

Justin Traglia: If I'm understanding this correctly. I think I would favor passing the committee to the function instead of the full state. I can't even find that comment. Amazing.

Jihoon Song: Yeah, I think that approach would be… The cleanest one, at least for me. Yeah, I'm gonna wait, I say, to reply. After he wakes up. And then… Probably, I would go with committee as a parameter. So that we can kick off the release. Yeah. Only asleep, like.

I don't like any of these ideas, but I just cannot think of a better one at the moment.

Justin Traglia: I mean, we could just defer this entire conversation until later if you want. Hold on. Whatever you think is best.

Jihoon Song: Yeah, I think we… I'm gonna just go with Committee. I think it's slightly better than state. But it's not… Frozen, yes, so we can change it later. Right? Yeah, and after this PR, I might make several PRs that add That's the cases. Okay, that's all for spec changes. Do we have any questions or comments?

Otherwise… We can go ahead and wrap up this call. Thank you all. See you in two weeks.

Barnabas Busa: But just a quick question, when do we want 10.0 to launch?

Jihoon Song: And the clients already.

Barnabas Busa: Yeah, so… we have done an 8. Programs for them, everything now. I would expect that to be quite stable. So, in approximately 2 weeks, I think, it could already… consider launching W04 FOCIL, if you have a few clients. Maybe target, like, end of August.

Jihoon Song: End of August is, just, like, a week, I would say… Yeah, I think it's up to clients, but my opinion is, if you want to make a little bit ambitious, then we can target next Breakout call, which is 2 weeks from now. I don't know, yeah. Yeah, we can just tentatively target for… the 31st of August, and then see how it went. In the next Breakout Call. Right? Thank you, guys. Dan. Nice. work for the first DevNet for FOCIL.

I'll see you guys in 2 weeks.

Fabio Di Fabio: Great, thank you.

Jihoon Song: I bet.

Justin Traglia: Yeah.

Marc Harvey-Hill: kiss, but…

Mehdi Aouadi: Thank you, bro.

Cristian Conache: Thank you.

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