FOCIL Breakout #17

Transcript

[Music] What's up?

Jesus. Heat. Heat.

Heat. It's already 03, so I think we're good

to go. >> Bye. >> All right, then. Um, hello everyone. Welcome to the 17th Boss Breakout. And this one could be a nice and short one. I guess we can share some news what we are going to do for the upcoming weeks and then we can share some progress if anyone would like to. I guess we can begin with good news. As everyone knows, we got CFI for Glamsterdown. I'd like to take this opportunity to appreciate all the support from the community researchers and developers who have been working on

fossil. But it's not over until we actually ship it. Now I believe our utmost goal would be making sure fossil doesn't delay Glam Amsterdam more than necessary. It's super only to discuss or estimate timelines for Glamsterdam but still we can make progress in independent topics such as testing. I think from my perspective we could do two things in the very short term. One would be rebasing on the flu and then EPBS and then second would be adding test. So Justin here shared the rebase plan of

EPBS in the EPBS discord channel which is rebasing EPBS onto flu and then renaming it into glowas. After that we can start rebasing onto flu and then eps. I created a draft PR that demonstrates how fossil can be rebased on eps. It's not reviewed yet, but if you'd like to get the sense of how the rebate is supposed to look like, please take a look into the PR and I also made a write up about it. So, if you prefer a write up, we can also offer that option for you. Let me share the links in the chat.

Yes, thank you Jillian and thank you for all your uh research and like included so like for example yeah so these are relevant articles that I produced for past few weeks so that was for the rebasing part for testing part I'm planning to add some unit tests that are independent from the upcoming rebases such as I committee assignment I processing logic such as equipocation handling and so on so forth. So that's it from my end. Um does anyone have any question comment or some progress to share?

Uh I would just like to quickly state that the rebasing fossil into EPBS will look a bit different in practice. Instead of merging uh fossil specs into the like EIP7732 spec, we'll essentially just keep the EIP785 spec, but uh change the the diff essentially. So uh I can explain it more in detail if you want later. Yeah. Um, do you want to discuss it offline or do you want to go over it here?

>> I think offline would probably be best. >> Okay. Yeah, we can discuss it in, you know, Discord or somewhere and thank you for the thank you for the pointing it out. Um anyone else? So we have three core death here who built um boss prototype in low star tu and nethermind. Um do you guys can foresee how the fossil development would

go at least in your team that's going to be like commence after EPBS is done or would it be able to you know allocate some resources in parallel? >> Yeah, I can give an update for from TEU side. Um yeah, basically I've been working more on finalizing um Fusaka fork the last days, but I'm going to jump back into for uh on our side. There is still the um new spec changes that have been merged like few weeks ago that need to be implemented. But that won't be very complicated since we already have a working prototype. So it requires

some changes and then as we are going to rebase uh fossil uh on top of the fulu that would be nice because we have a separate branch for fossil that need to be rebased on on top of our master branch which includes all the fulu changes. So basically those are the two main steps that we have to uh to do in order to be like um to finalize our uh foster prototype. Uh in the team we have other people working on EPBS. So we have kind of two separate branches but um yeah I'm working closely with the uh

people working on EPBS. So we might at some point maybe create a branch uh where we have a prototype of EPBS and fossil working together. So that would be the uh third step. So that's basically the plan from our side. Hello Justin. Yeah, thank you Maddie. Um then what do you think about working on rebasing auto to flow for the upcoming weeks if there is any developer who can afford it because yeah um we um considered this option

few month ago but we just delayed it because uh we didn't know that we can you know somehow help fossil survive but now that we can you know consider shipping it uh maybe it's good time to working on replacing it onto flow across client teams. >> Yeah, I was thinking about that maybe even before starting to implement the uh new spec changes that would be would be maybe uh better to base it on top of full first and I could allocate some time to it uh from next week. Uh I guess I could allocate few days to do that. Uh to be honest, the branch diverged a bit.

So it could be a little bit painful, but I cannot guarantee that I can have a working branch with other CR CL clients. But yeah, I can give it a try definitely next week cuz then I'll be off for a couple of weeks, but other people could jump in. But yeah, let's say I can start uh I can try rebasing it on top of follow um next week. >> Sounds great. And I speak of which I just remembered that we have some changes in Q in the execution APIs back such as using fork choice updated instead of update

incidential list update payload with collision list API and like um I guess there were like three to four points but I don't remember everything on the spot but um maybe we and work on that together. So that so so the final I mean yeah so so so next checkpoint will be running a local devnet with multiple clients with up to date execution APIs of course. Yeah. Yeah. Cuz those are breaking changes, right? If we don't Yeah. Yeah. Okay. Okay. Okay.

>> Yeah. >> Uh yeah, definitely. I need to keep that in mind. Okay. I bet you prioritize that then. >> Okay. So, uh so um I just want to ask how core devs think about this. So I guess we can uh consider two approaches. One would be rebase on to flu and make the breaking changes in the engine APIs. The second option would be rebase on to flu first without any changes in engine APIs and then work on the engine API changes later.

Not sure which one would be better. Yeah, honestly I don't have a strong opinion on my side. I'd be more inclined to rebase on to follow first then maybe implement the breaking changes. >> All right. I guess >> yeah I guess these changes um I think I can just prepare two versions of G prototype. So one with current version and the other with the updated engine API version. So I'm not sure what CL devs would prefer but which way we going to choose down the road. Uh I can just prepare get prototype ready.

So yeah margos and EPBS together. Um I from the standpoint that we are at I cannot come up with any new changes on the engine API. Of course, there could be some engine API like um you know like using for example using new payload B4 instead of B5 like this kind of versioning thing might be changed not sure but besides that I guess the general selection set would stay the Hey, I hope that answered your question. Um,

is there any question or something we can discuss? All in one go. All right. Yes, Katya. >> Yeah, I almost done with the um Gort's dashboard. Uh I just had a review from the team and need to make a tiny updates. Uh so probably I will just wrap up into the HackMD article and share in the chat. So yeah, we'll have a quick dashboard for I hope to finish it this week.

Thanks. >> Great. Great. Um >> but this is only for CL. So I build it on lowar. Um yeah and probably will we will start from CL and then move to Yale. I hope so. >> Yeah, makes sense. Makes sense. These are the metrics we discussed on in learning. >> Nice. Please share the hack when it's ready. And great.

Uh all right. Do we have any other questions or something to discuss? Going once, going twice. I think that's for today. Thank you everyone for joining our call and have a great rest of your day.

>> Thank you.