FOCIL Breakout #38
FOCIL Breakout · 21 Jul 2026 · 36:31
FOCIL Breakout #38, held on 21 July 2026. FOCIL, or fork-choice enforced inclusion lists under EIP-7805, is a proposal to make it harder for block builders to censor transactions. Lodestar was blocked on changes for progressive containers merging to its unstable branch before rebasing, and Besu was on Glamsterdam devnet 6.
Speakers
Topics
From FOCIL Breakout, hosted by Ethereum Foundation.
Transcript
Justin Traglia: Good morning.
Jihoon Song: Damn.
Justin Traglia: I'm just waking up, by the way.
Jihoon Song: How are you feeling? How's your throat?
Justin Traglia: I'm still coughing a lot. I don't understand how this keeps happening to me. No, it's fine, man. I actually got a decent night's sleep, so that's good.
Jihoon Song: Nice to hear it.
Justin Traglia: It's all your message on Signal, I'll respond. After this call.
Jihoon Song: Okay, thanks.
Justin Traglia: - how are you doing?
Jihoon Song: Doing great, you know. I just keep finding… Something to fix in… in the spec. They're making small PRs.
Justin Traglia: Life. Hey, Nico, how's it going?
Jihoon Song: Hey, Nico.
Nico Flaig: Yeah, so you just fixed, this max request thing. I think that confused me today as well, why it was 2.
Jihoon Song: Oh, yeah. My bad. If you… if you think the fix is correct, please feel free to approve it.
Nico Flaig: Yeah, I think it's correct, but I didn't really think too much about it yet. I can take another look.
Jihoon Song: Yeah, no hurries. Oh, hi. Hi, Fabio. It's been a while. Heavy here.
Fabio Di Fabio: Yeah, yeah.
Jihoon Song: Hello, I think we can wait a few more minutes, and then start.
Alright, I think… We can start. Hello everyone, welcome to FOCIL Breakout. 38. Today, we can share Development updates and spec updates. Yeah, let's start with development updates. Do we have any? Updates from Lodestar, and… Besu.
Nico Flaig: Not really from Lodestar's side, so still waiting on some stuff to be merged to our unstable so we can rebase. So, we are mostly stuck on the 7688 changes. But yeah, that should be soon done. And then probably we rebase on devnet 7, is my guess.
Jihoon Song: Gotcha.
Fabio Di Fabio: So, Besu, we are on, Dev Glamsterdam DevNet 6. And the… Yeah, I don't know if there is an update. or the… I've test in order to run on DevNet 6, because the last time I tried. Two weeks ago, it was not… Alrighty.
Jihoon Song: Yeah, so, we don't have any updates for testing, but Yochum will gonna help us for… execution tests. He told me that he was gonna start looking into this starting this week, so we can expect some changes in the… And, yeah, in the East.
Fabio Di Fabio: Okay, great. Yeah, that's rule for as well.
Jihoon Song: Alright, thank you. Alright, I think we can move on to… Spec updates… For spec updates, I have… One question to answer to… depth, it's about… the PR is this one. So, my question is about getting credential list. So, currently, getting colludentialList EnginePI has a block cache parameter. But if the CL and the EL have the same view for the head payload. This might not be necessary. So the situation is, payload due is… at 6 seconds into the SLOAD, and EL due is 8 seconds. So the question I'd like to ask is. whether the CL and the EL already have the same payload, the same, yeah, the same head payload by the time it calls GetInCollectionList.
As far as I understand, all clients… I mean, all EL clients call FCU after receiving a payload, but I'd like to double-check on this if this is true for all cases.
Nico Flaig: Yeah, one thing to point out, maybe, is we do call FCU, but the payload might not be executed yet, right? So if it… I'm not sure how the EL will handle this, if it takes longer than 2 seconds to execute. Or it could even be way longer, right? For the EL to execute.
Jihoon Song: Hmm.
Fabio Di Fabio: Do you mean you are… So, if there is a sequence with a new payload and a fork choice update. At that time, we should always have the payout. You are saying there could be cases where there is a fork choice update without… A new payload in this case probably is because the EL is out of sync. Is that correct, my interpretation?
Jihoon Song: I think what Nico is describing is when the new payload call takes longer than 2 seconds, so when you… When you… when the EL gets GetInclusual list call, the EL might be still processing the new payload call.
Fabio Di Fabio: Doesn't the EL wait synchronously until a new payload returns?
Nico Flaig: Yeah, exactly, that's the main worry I have. Like, the deadline that Jihoon mentioned is at, like, 6 seconds, but this is only for the payload to be available, not executed. So in Loadstaff, for example, we call this, we call notify a new payload, and then we wait for that to respond. And then, after that resolves, we will call, FCU. So, depending on how long the notify New Payload call takes? Depends, yeah. So FCU might not be called at that point.
Fabio Di Fabio: I see, I need maybe to double check, but in the basic case, we… should only return from new payload when It's stored? then… Yeah, whoosh. that point, so… is only stored? But the ad is not moved, so with the fork trace update, we'll move that. And at that point is the new canonical. So… Yeah, I need to review better the timing. So the issue is that if the new payload is not yet the canonical lead, we can have staler results.
Jihoon Song: What does EL do when they didn't receive a payload? Do they still call FCU?
Nico Flaig: No, in loads that we don't. I mean, we might do it when we… let me double-check… when we import the next block, basically. Bot… So if the app doesn't change, we don't really call SU.
Jihoon Song: Yeah, unless… the head changes, there's no reason to call FCU. I'm thinking about… whether, the EL and EL are… on different forks. When calling, GetInCollisionalist. Because I'm just, like, thinking about, like. why does the CL have to specify block cache? It is similar to, calling FCU, so, like. They don't need to… Tell the EL to build intelligently based on the head payload or its parent payload, because that's up to the EL. It's kind of, like, transparent to the EL. What matters here is whether they are on the same… Bridge.
Fabio Di Fabio: So it's also true that, I'm talking for Besu, so I cannot say about others. Clients, not… the Transaction Pool… From, where the inclusion list is, fetched. doesn't… Change if you… Etsy is… When you call Get Inclusion List, Even if you… Pass a block cache that is not the current ad. It will say… In the best case, it will say there is a mismatch, so the result could not be accurate. could be stale. But we try best effort to return something, so… It's not that we can…
Choose what to return depending on the block cache that we get. We just can… Worn… the user. That's… the request. doesn't match the current chain net. And in that case, we try to return something best effort, so… That could be just expired transaction, because Maybe the, the new fork choice. For the latest block is not yet… fully processed. You try to get something, but you probably get transaction that could be already be confirmed.
Jihoon Song: Hmm. Yeah, makes sense. Yeah, I think I need to think more about this. Another point that brought this up was… the intention of this block cache parameter is point to the head, or the parent of the head, but then… It has to specify that it allows… To receive this block cache for the recent two payloads, not… for any block. And then… it kind of escalated, like, do we actually need this parameter? And then, yeah, we need to consider many cases. So… Okay, let me think about this more. I believe this would be the…
last blocker before merging these Engine APIs, so… Yeah. Okay. Besides that, I'll be working on revamping EL Store starting this week. So, I've modified the request response for… in commercial list, and… 5424? And this causes several changes. Firstly, EL storage store signed intelligently, because it has to respond with signed object for request response. I also feel like… Current code has quite a room for improvement. Also, when a node fetches on an IL via request-to-response, it will feed it on EngineList. Currently, it only handles IELTs from P2P, so it has to be changed.
And seeing a lady opened a PR handling this issue. This is NSSPR. But I'm thinking about replacing Inclinus Committee Road with dependent route, so I might open another PR. updating on England. So, yeah, this is currently what I have in my mind regarding spec changes. Next to this step will be making it compatible with frame Transaction, but… Yeah, so, kinda put higher priority on… Frame Transaction thing, because… This might be already enough for the first few dev notes. once we figure out how we can make it compatible with Frame Transaction, then… I think I'm gonna start working on…
Considering the bitlaze in the fork choice. So… Yeah. just sharing. Do we have any questions regarding… Spec updates were… Anything?
Fabio Di Fabio: I have a question, if we can go back to execution specs. I think… maybe it's something that you already… Talked about, but, I'm not sure, so… In Paris, in the payload building section, It says that client software Should be an initial version of the payload. Which has an empty transaction set. does this, should be updated for Bokuta to tell that initial block should include Only the inclusion lists.
Jihoon Song: I don't think it has to be, because there could be, some inconclusional list that turns out to be… Excused at the end of the building process. And… Because… We don't enforce any ordering rules, so it's up to builders to decide when to include in-closure list transactions.
Fabio Di Fabio: Okay, because the idea of this was to always be able to return something that the CL will use. As a pollut. Anyway…
Jihoon Song: Yes.
Fabio Di Fabio: In our case, if we don't include at least the inclusion list, It could not be. I don't know. Let's say the block is valid, but doesn't satisfy the inclusion lists. So, just wondering if… in Facebook, for example, I… what I did is to… since I have already the inclusion list transaction, when we start building the block. Instead of building the empty block. So the block with no transaction. We built… The block with only the inclusion list transactions.
Jihoon Song: Yeah. It is…
Fabio Di Fabio: puts this… Could be that it takes too long, so we could not return anything at some point, but… At least we tried to return Something that could satisfy the inclusion list as well.
Jihoon Song: Yeah, I'm not entirely sure why we have that spec in Paris, so… I'm gonna ask around why do we enforce to start with empty payload in Paris, and then, get back to you, but I feel like, we don't have to change the spec, to make this… Change minimal, but…
Fabio Di Fabio: Yeah.
Jihoon Song: It's good to revisit. Why we have that, specification.
Fabio Di Fabio: Okay, it was just to write something that I found during the implementation.
Jihoon Song: Yeah, great, yeah. Thank you.
Nico Flaig: Yeah, so I had a question regarding NCSPR. So, is the intent really for the RecRASP to be used by testers as well? And if that's the case, when would they call this?
Jihoon Song: they would call it before ILD, if they want to fetch some missing IELTs. Before… yeah, because from… from… so, for our testers, sorry, for… a proposer and builders, they were gonna consider all intelligent lists, regardless of timeliness, and all validators, other than a proposer and builders will gonna consider only timely intelligent list. So, if they call this request and response after the ILD, then it will go to untimely anyway, so it's kind of like a no-up, or not honest behavior.
Nico Flaig: Yeah, the case for proposals makes sense to me, but I'm not so sure about the testers, to be honest. Because there isn't really a time where you… when you would call this, right? Maybe implementation-specific, but we are also not doing this for, like, other messages, like PTC, or… At the stations, even, right? So…
Jihoon Song: Yeah, I also think so, but… Do you think that we have to check if the requester is a proposer or builder?
Nico Flaig: No, no, I was just thinking, like, attesters shouldn't even call regress. I mean, implementations can still do this, but not as part of the honest validator spec.
Jihoon Song: Yeah, I also think so, like, I didn't mean to, you know, imply that testers kind of have to implement this somehow, because it is technically an option. I'm just saying that, from a spec perspective, it is technically possible, because… of how this request response is designed, but in practice, I don't think that this will be used other than a proposer and builder's. Or do you… I think that maybe we need to mention this somewhere in the… in the request response?
Nico Flaig: I mean, for now, probably not. I think it was mostly one comment you left somewhere on the PR.
Jihoon Song: Yeah.
Nico Flaig: Bot suggested that, but yeah.
Jihoon Song: Yeah. Yeah, I was… I meant that… I mean, technically it is possible, but yeah. I should be more, explicit.
Nico Flaig: The other thing that confused me in this PR is using the slot times the slot duration. So shouldn't we just make it so if the inclusionless slot is not the current slot, then it's not timely?
Jihoon Song: Hmm.
Nico Flaig: Instead of changing it, how NC did it, like, the formula at the bottom of… on Inclusionist.
Jihoon Song: But… It might be called way before… the EL due. So, I think it is not sufficient to just check SLOT.
Nico Flaig: Oh, but then the… Current slot is the inclusionist slot, and then you do the previous calculation, right, where you say…
Jihoon Song: Oh. Oh, you…
Nico Flaig: Calculate the timeliness, right?
Jihoon Song: Yeah. It's also possible, I think, like… Maybe we can compare to code and see… Was more simpler and better.
Nico Flaig: Okay, yeah, so for now, we just implement this for proposals, I guess.
Jihoon Song: Yeah, for clients, yes, and for builders, I think? Not sure if you have a…
Nico Flaig: Yeah, I'm mostly not sure how we test this. Like, if you run it on a definite, we're probably gonna observe anyways all the IELTs via gossip, so…
Jihoon Song: How do you usually test request response?
Nico Flaig: I mean, usually it's for messages we missed on gossip, right? Like, you receive an attestation you didn't see. Oh, sorry, another attestation votes for a block, we didn't see it, and we tried to get the block, but… I think it's not tested well on the DevNet, to be honest.
Jihoon Song: Do we test it on testnets?
Nico Flaig: I mean, you can make the proposal withhold messages, right, and then… Yeah, I don't know. Maybe you can ask Panda Obs?
Jihoon Song: I see. Yeah. So intention-wise, this request-to-response will be used by a proposer and builder, not testers, so maybe this is something… some useful information for implementers. Not sure how to specify this, or… If it's necessary to specify this, but we can just leave it as is and change it later if people found it, confusing. Right, do we have any other comments or questions?
Nico Flaig: Is there any timeline for the first devnet? So we can start planning a bit. I'm hoping we stabilize Gloas, I don't know, a bit, so…
Jihoon Song: Let me check… Devin at 7… how is devnet 7 going? It looks fine. Yeah. Honestly, I don't have a timeline at the moment. But… My hope is… We can stabilize the spec soon. Except, fork choice with… ILP list. And then… just working on this. FOCIL DevNets… And in the meantime… I can start working on… Frame Transaction. So… Yeah, but I don't know, like, it's still, like, months out. So, yeah, I don't have a good answer for timeline.
I don't know, maybe we can revisit it, like… And in two weeks or so. End of August.
Justin Traglia: maybe we could wait until the first, testnet is upgraded to Glamsterdam, so that we know that things are fairly… Stable. with certainty.
Jihoon Song: That's not scheduled yet, right? The first testnet.
Justin Traglia: It is not. I think it would probably be, I mean, I forget what Perry said, but I think he said… I think he said end of September. I don't recall.
Jihoon Song: I see, yeah. Honestly, I don't think there is any reason that we need to rush, so… But we can always try local interrupt. Nico, do you have any opinions?
Nico Flaig: Yeah, we're probably fine with local as well. I guess the main issue so far has been that, like, we changed the specs so much in Glamsterdam, so we never… Like, there was not even a few weeks where it was stable on a base, so… Yeah, so I think it's probably fine to… tried to launch something locally on Alpha 12. So I guess we just need to update Lodestar and Besu, maybe, and then we can start testing more.
Justin Traglia: And, we can make a new release for you guys with the changes that everyone's made this week. the past 2 weeks, I guess.
Jihoon Song: Yeah, but… I would like to ask to wait a little bit until, this IELTS score, gets revamped. Because it will be gonna change anyway.
Justin Traglia: Yep. I wasn't, suggesting we make it, like, this week. Ideally, we wait until, like, 5 days before devnet 8. Just in case there's any breaking changes there. Needed for that.
Jihoon Song: Yeah, makes sense. Like, 5 days before DevNet, I should be… sufficient, but do we have any schedule for DevNet? Sorry, I was just like…
Justin Traglia: Yeah, at ACDC, we said, like, 2 weeks from now, pretty much. It's not like, There's no set date, but around 2 weeks from yesterday.
Jihoon Song: Yeah, 2X is, yeah. That's doable, yeah. Alright, so, we are tentatively aiming for the next CL spec release. like, a few days before DevNet 8, and then we can try to make local interop. Probably between Lodestar and Besu. To summarize. I should probably do an out for a second. Great. Thank you, guys. Do we have anything else to discuss?
Awesome, I think we can… go ahead and wrap up this call. Thank you, everyone, for joining. Have a great rest of your day, and see you in two weeks.
Fabio Di Fabio: Thank you.
Nico Flaig: Thanks, Sue.
Justin Traglia: Hi, everyone.
Fabio Di Fabio: Thank you.
Transcript adapted from ethereum/pm, CC BY-SA 3.0.