FOCIL Breakout #18
FOCIL Breakout · 26 Aug 2025 · 20:15
FOCIL Breakout #18, held on 26 August 2025. FOCIL, or fork-choice enforced inclusion lists under EIP-7805, is a proposal to make it harder for block builders to censor transactions. These breakout calls cover the spec, client work and testing.
Topics
From FOCIL Breakout, hosted by Ethereum Foundation.
Transcript
Heat. Heat. [Music] Yeah. Heat.
[Applause] Are we ready to go?
Thank you. Hello everyone. Welcome to the 18th fossil breakout. I think you we really never had any break since we started this breakout call which is amazing amazing EIP and amazing people. Today I'd like to share a few updates on rebasing and testing and then we get we can go over development updates. Justin has rebased fossil spec on top of flu two weeks ago and then Justin and I discussed about how to go about rebasing onto EPBS.
We could use two track approach here. We can have the master branch remain on top of flu while we have a longstanding PR that rebases fossil onto glow which already has the PBS spec. Um we already have that draft PR and I can update that PR from time to time so that it doesn't get outdated too much. Uh this is yeah this is the link to the Justin's PR in case anyone's interested.
We don't have much update on testing. I will be publishing a document that lays out test cases thoroughly such as its input and output and what it tests. We discussed this with the protocol security and steel teams and we believe this would be very useful. So that's it for the rebasing and testing. Please feel free to add if I missed anything. Um besides that before we jump into development updates, do we have any questions or comments?
Yeah, I I have a question about the um glow fork um cuz I I've been rebasing fossil on top of fulu for teu but now we have the all the glow boiler plate code uh and I was wondering if we'd want to keep the um feature fork like we did uh during the last testing round or uh do we plan like to to consider glow the fork to activate um fossil um I'd go for this option in my opinion but I don't know what other client teams think about that >> you go for which option exactly >> if we if we keep um either we keep a um
a feature fork or we consider for um activating fossil from glow. I I prefer the second one which means uh activating it on glow. So >> okay. Um interesting. What do other clients think? If we're going to do glowas, that means uh we're going to merge full solo with the EPBS, right?
>> Yeah, in my understanding that would be the case. But yeah, I guess >> as far as I can tell, only Teu and Prism have uh the EPBS code. So Lowar and uh Lighthouse don't have it yet. I'm not a client, but I think keeping it based on Fulu and testing as a future fork might be simpler for now until uh EPBS uh spec stabilizes a bit more.
Yeah, I kind of lean towards that as well. Yes. So we can also wait until the PBS implementation be stabilized more. And if I remember it correctly um when we discussed about like whether we CFI fossil uh one of the argument is that fossil will remain as a feature branch. So it would not delay galas fork even if we decide to defy it. So yeah um so maybe we want to
remain on top of full loop both the spec and implementation and then we can try to rebase it on top of colas after we have or stabilize the pbs back and implementation. Yep, that's my plan. Uh at least and then that would remain as a future fork after glow. But then if it is SFI if uh also SFI we would then just uh pretty much merge it into the glow specs and they would have it at the same time.
>> So we'd want it to be a feature fork after the glow, right? Not after photo. That's what I I wanted to understand >> eventually. Yes. Okay. >> After specs have stabilized to a point that like >> that works. >> A change there won't affect the fulle um like dev notes. >> Okay. All right. Um, do we have any other points to discuss?
If we go with this decision, does it going to add a lot of complexity for implementing it in tech? I guess because >> actually it would even make it better because since we already have the all the boiler plate code for glow um that would mean that the fossil branch will um keep the same track as our master branch. So that's that's better cuz otherwise I need to keep a divergent branch only with full and without all the glow stuff. Um I already rebased it uh rebased the the branch on top of uh
Fu. Uh I need to um cuz the glow stuff has been added only recently to our code base. So I need to do another round and um yeah I guess that won't be too complex. That would be okay. >> I guess I Yeah. >> Yeah. If we um activate fossil after glow um >> are we going to have both EPBS and fossil or are we going to have fossil? Not necessarily because um for now at least we didn't merge any EPBS related stuff in our codebase and um so yeah for now it won't be that won't be an issue >> right so glass is just a
>> activation >> yeah exactly the same the same thing we had with um with vector fork I guess before we merge yeah >> yes great all right I think we can move on to the last agenda which is development updates. Um so besides this uh feature fork on top of glowas do we have anyone have anything to share? Um, fo star we also rebased uh, fossil on top of fulu and then um, we implemented some of the
newer spec as well. So the uh, inclusionless store and we also updated the uh, the engine API calls. Um there's just some minor stuff that I need to wire in and other than that um it should be ready to um do some testing and uh and also the beacon API specs uh have been updated uh to reflect the latest spec. Uh that's pretty much it.
>> Great. Great. Um did you try with uh the interrupt with the get that reflects the updated engine APIs? >> No, that would be my next step. >> Right. Um if you encounter any trouble, please let me know there might because it's not tested. So it might there might be bug. >> Yeah, sure. So for maybe um is it correct to understand that teu has been rebased on
top of fulu and maybe um you are going to work on the updated engine APIs I guess. Um yeah, that's that's not done uh yet. Uh the engine API uh update and the um the whole uh inclusion store uh redesign. Um I need first to uh incorporate all the um grow stuff and then work on that. And unfortunately I'll be off for a couple of weeks. So uh that won't be ready before a couple of weeks. I guess by the midepptember maybe we we could see something working
on the tech side but not very soon. >> That was great. Do we have any updates in other client? Maybe B maybe maybe Bessu or Nethermine or Wrath. >> Uh Basic doesn't have any updates on implementation. It's kind of behind some of the uh scaling to 60 megga gas per second. So, um, I'll notify you when folks free up and can start working on
it, but right now doesn't seem likely. >> Okay, cool. Thank you. All right. If that's all for their client updates, then maybe. All right. So, Nethermine is currently focused on bells, which is okay. Yeah.
maybe Katya, do you want to share something about the metrics? I saw you shared the hackmd slightly before this breakout call. >> Yeah, I just uh built an initial list of metrics and uh uh the cortis dashboard for it. Uh the links are in the hackd article. So um I would like to hear from you um which of these metrics uh can be helpful or useful uh which are not and which metrics uh we need uh besides of this list. Um so yeah so we can discuss it in the thread.
Um yeah, I attached the screenshots in the article. So um you can just look into it and the config also is in the article. Currently I'm trying to update uh Docker image. Uh I have some issues with it uh rebased on FO. So yeah, probably a bit later I will just update uh the Docker images and uh would be great uh to get some metrics from the E side. Uh Jun if you
have any ideas we can also discuss in the thread. >> Yes. Um, for the VCON metrics, uh, it would be really nice if CL devs could provide some feedback to the HAMD article and for the metrics on the E side. Um, I think I need to take a look into it more, but yeah, let me share my thoughts if I have any in that thread later.
Yeah, this beacon metric can be like initial uh for just for start and uh we can proceed with both CL and DLS. >> Great. Great. Sounds great. >> Yeah. So medie um I can take a look into the tooling such as curtosis so that we can have EIP705 fork after glow. So for um I'm not sure if curtosis supports golas uh genesis generator so that we can have glowas at epoch zero and then we can
have eip7805 at epoch one. Um yeah, maybe I need to take a look into that first but yeah, let me take a look into that so that we can just work on this inter after uh colas. >> Yeah, sure. Currently with this config um it's quite stable. So it can run for some hours and yeah, no issues with that. But yeah, we have like a lot of updates. Uh so okay great right so rev is catching up to the news
back changes and rebasing onto flu which is great I guess we got all updates from core devs in this room um yeah besides Do we have any more updates to share or just you know any questions, feedback or comments? No updates from Justin. Um, all right.
Maybe we can wait like 5 seconds until we have more updates and then we can just wrap up this call. Going once, going twice. All right, everyone. Thank you for joining our breakout. Hope you have a great rest of your day and see you in two weeks. >> Thanks everyone. >> Thanks. Bye. Cheers. >> Thank you. Byebye.