FOCIL Breakout #13

FOCIL Breakout · 17 Jun 2025 · 21:18

FOCIL Breakout #13, held on 17 June 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

[Music] record number 13. Uh yeah. Um so as I said, I mean last week was in Perup and it was pretty crazy and things are still happening uh in Berlin. So I think this should be like sort of a nice and short and quick one hopefully. Um and we and there is no like presentation or anything. I think we can just like discuss things that are like top of mind.

Um so yeah what did I I'm still like s sort of like gathering stuff around for soul and how it went during the interrupt. I think maybe it's some overall comments or um well first I think we had a nice fossil session uh people like really liked it and it was sort of like a very packed overview of what's happening around fossil during one hour and I think the session was I don't know useful and uh so that's cool then generally like everyone I talked to was I don't know it it really seems like

there is like a overall general consensus on fossil being important. Um I don't know you can see it across presentations you can see it when you ask people what they think whether there are researchers or core devs. I feel like everyone sort of like is on the same page and and thinks for like is uh going going to be like an important part of the future of the protocol. Um the only thing that's left to determine is like the urgency. Um and that's a bit more v variable like people some people think it should be included as soon as possible like and it's very urgent. some other people

think it might be okay if it comes in the protocol a bit later. Um so that that's really like the sort of like contentious part but I would say on its importance and on whether it should be included um in the first place is looking really good. So that's very nice I think. Um couple of comments. I think some people noticed that um we actually might need nel limit in gas and not just in kilobytes. Uh and that's to make it work with the provers in the future because

if you don't limit per gas um then like basically you can include very worst case I for provers to deal with via fosil which isn't like uh something we want. So we need to think about um I mean changing the IL limit from kilobytes to gas. I don't think that's a big big overhaul to be honest. Uh I think we just need to settle on like a value basically. That's not too small.

Um hopefully it still covers like I don't know like the all transactions that are usually included in in a block today. I think that would be ideal. Uh that was definitely the case with like the 8 kilobyte limit. So we can see whether it's like two three million gas. Um I don't I I I'm wondering if you guys also have ideas about like the good uh size limit in gas that we should probably uh have. Um but I I'll keep giving it some some thoughts. Um then good news I think maybe I'll let Jun talk talk about this because he he also has like insights and he he was the one telling me a lot about this. So um

but yeah both mostly like like more clients interested in in implementing for which is always like a very good news and a good sign. Um so yeah I'll let maybe Jun talk a bit more about this. And then the one thing I really wanted to mention is um yeah that we need to focus on tests. Uh I've noticed in a couple of conversations that uh people are even mentioning you know maybe uh EIP that are considered for Glamster should have spec uh tests in included in in their like devet or or like

implementation for it to be even considered for inclusion. So I think we might need more of an effort on tests like in the following weeks uh if possible. So I wanted to check with you guys on that. Um and unfortunately Jacob was looking at the tests on the E side and he's not going to be able to continue work working on this. So yeah, I think someone needs to step up. So I don't know if like anyone here is willing to do it. Uh it also I mean you can also like just DM me and and we can um chat about it if you are ever interested. It

will be definitely in collaboration with the steel team. Um they said they will be like willing to to help on that front. But yeah, basically um on the CL side, I think Jiune might um refocus on on on tests uh on the CL, but we need someone on the E side. So, if anyone is willing to help there, uh that would be really good. Um and yeah, that was pretty much it. Um let me know if you have questions about the interup or how it went generally. Um but yeah, other than that, I think Jun wanted to talk about a couple of things.

Yeah, thanks for sharing the update. Uh regarding the EL spec test, I can take it over. Um I'm planning to like I expect I can uh finish the CL spec test in few weeks like one or two weeks. My m major bottleneck was uh filling up the holes in the spec test. No sorry in the sales spec and it's done so I don't think it will take like much time and I also met Guru from he steam yesterday so I can take it up uh and another feedback that I want to share that we had during the interrupt is that we might need to shift the freezing

deadlines uh because uh over the time we expect to raise gas limit and raising gas limit will increase um I'm sorry raising gas limit um might make local builders run out of time. So we want to like for example currently we have uh 9 seconds deadline for testers and 11 seconds deadline for builders but we might want to move it to like let's say 10 seconds instead of 11 seconds to give local builders more time to update their payload. Um that's also we want to think about and the second yes to yeah uh just about your last

comment I think you're completely right and it's a good good observation I definitely think it should be included in this look at different uh deadlines based on like the side of the the size of the block you would have to build for a local proposer and you can always assume that like I don't know sophisticated builders will be much faster anyways or so so yeah I think that's a good comment but it could be included as a test just like as we try to actually you know increase the size of blocks uh that will be built by a a local

builder or proposer we can we can just test this out and see whether the deadlines hold. You mean after we let's say if we have both in coldam um we want to decide to whether move the breathing deadlines after we see how it goes in the real world or are you suggesting to run some tests as some at the public devst to figure out what would be the better phrasing deadlines before we ship basel. Yeah. The second one I think having an idea of about like whether the deadlines will hold under like blocks with higher gas limits will be nice to have before

we ship fossil. So we can prepare for what's next because we're pretty sure like the gas limit is going to increase anyways. I don't think there is like a ton of uncertainty around this. So, might as well just like test it before we even ship it. So, we don't have to like change the deadlines of for um after like gas increases or at least it's not like a blocker for for any scaling things. Yes, totally. So, uh to summarize, we want to um have a good insights on two things. One is uh phrasing deadlines and the second thing is um uh what was it?

Uh oh Jesus I forgot uh could help to I just forgot what the other thing we want to test. Oh right guess on block size. Yeah yeah yeah guess limit right. So we want to figure out those two things. Sorry. And then um secondly regarding the interrupt. So we thanks to Ethan here uh we on boarded a lighthouse. So we have five clients that work in the interup and then um maybe we can invite Nethermind.

Uh Mark is also interested in working on that. So we might figure it figure that out um in this week or next week. And also um looking at EPF cohort 6 um I've still like three to four people interested in uh developing fossil and grand and nimbus. So after like few months I expect to have like nine out of 11 clients succeed in interrupt uh which is really cool and then yeah I think that's pretty legit for for my end.

Nice. Yeah that's that's really awesome. I think yeah even talking to some of the core devs that during the interrupt some of the teams like didn't start implementing fossil but were feeling already quite strongly about wanting to cheer for it for for the next fork. So yeah I think you know um a lot of things are going to be a bit more clear after the deadline for headliner is uh is passed which is like in a month or something. So yeah, um it's it's nice to on board more and more clients, but um I I think we'll all have more clarity exactly on the timelines for for everything in in not so long, which is

nice. Um okay. Does anyone else have something they want to share or I don't know questions about the interrupt? It was pretty packed. It was very dense. Um but I thought it was nice. Um I'd like to write the uh question about rebasing um fossil spec onto uh fulu. I don't know what uh other team thinks about that because um for example in tech we have all the uh furu boiler plate already margin master and unfortunately uh the fossil brand started diversioning and I

was thinking maybe we could uh rebase the um faucets back onto fulu. Yeah, that's a good question. Um, how do you feel about waiting for the headliner CFI sort of like decision uh before before like rebasing everything on Fulu like or do you think um it's like quite urgent and we should do it like sooner? I mean the sooner we do it the better. But if we're talking like a month or two I I mean we can leave with that. But my thought were like even I mean

even even if we don't make it to Glamsterdam I guess we won't leave another fork without rebasing it. So in the end maybe we will sooner or later we will end up doing that. So that's what I was thinking. Yeah that totally makes sense. I think so from my perspective but I mean like I think more people should chime in. Um what I'm sort of sensing is a priority right now is trying to make the tests uh on both the CL and the E because that could basically be a deciding factor of for sale inclusion in the next fork. So yeah um I think I would want to

prioritize this over like a rebasing efforts if possible like just for one month but but literally in one month we'll have like the decision of CFI or not and then based and then we should rebase it in any case like whether it's CFI or not but um yeah but you know it would be it would be like an effort that we would need to do anyways. Yeah, sure. That sounds reasonable. Yeah, why not? Okay, awesome. Does it sound good with everyone else? Uh I think when we want to consider rebasing fossil on the flu another point that we want to consider is that uh we want to check like if pure duct is

stabilized enough because as far as I remember we avoided rebasing follow a bottle of flu as pure dust was unstable back in the days uh I wasn't following a pure dust development so I'm not sure if it's stabilized enough but uh if it's not stabilized crazy enough yet that we want to wait few months more uh because like it might be a hassle to just you know making possible work on top of like unstable pure if it is unstable. So yeah, right. Yeah, that's a good point. So okay, so then let's say for sure let's not touch it for one month and in one month let's reevaluate and by that time I'll definitely try to find out if it's

all um stable or if it's like changing a ton. I agree like if it's just like minor changes, I think it's fine and we can probably live with it because in any case like it's actually diverging and we will need to do it anyways. But yeah, that's definitely a good point. um to think about when we talk about it u in in a month. Great. Any other questions? So yeah, with Jiun we sat down with Katcha at some point and looked at the CL and E metrics for Fossil which I think was nice and will be very useful.

And uh yeah, there was also like a comment by the account abstraction team. I'll probably just write it down before I talk about it. Uh but um yeah, you know, like as a builder, let's say solo builder, um when you build a block, you have to like check if transactions that were not included in the block are valid or not to determine whether you know the block satisfied the conditions or not. And yeah, doing it that way, you know, can lead to some like worst cases in terms of computation time for local builders. Um, which, you know, I don't think it's like the end of

the world, but like should still be probably considered. And so an idea would be to ask the builder whether it's like a local builder or an out of local builder to include a sort of like hint list to indicate where that the transaction um was executed in the block um or like the attempt the attempt of execution was in in the Um so um so yeah so the the builder doesn't have to like sort of like try a lot of different combinations for for for

including like including transactions in in its payload in the first place. I think that's definitely something we will need in any case in the future. Um I've started to think quite a lot about like how also fits with ZKVMS and statelessness and I think this sort of hint or sidecar thing will need to like exist in the future anyway. So we might as well but yeah that's just like the rough idea. I will try to write something so people can also just like look at the doc and um see how it would affect fossil and and we make a decision based on it. But it's not a big big deal. It's just like a helper basically

to avoid like having to append uh I transactions to the end of the payload. Um so yeah, just wanted to mention it here. Um but I will definitely write something about it. Does anyone else have other questions? Okay. Uh if not, we can probably wrap this up. It was a very short one, but that was expected given the the intro last week. Um and we'll go back to a

more like normal I think schedule um starting in in two weeks with like more presentations and sort of like more content to to go on. Um, in the meantime, uh, exactly. Um, in the meantime, yeah, thanks all for for coming and, um, and see you next time. What's up?

Jesus. Thank you. Heat. Heat.