FOCIL Breakout #7

Transcript

[Music] rest. Okay, so let me do that again. Thanks everyone for for joining. This is Fossil breakout number seven already, which is pretty nice. Um, and we've got a good group of people uh working on it. Um, so yeah, before we start talking about maybe implementation progress and and blockers and so and so forth, I just want to give a very small update of um what we've been talking about recently.

Um so we were at uh an offsite together with a lot of researchers at DF and uh yeah one thing I want to highlight is like Fossil has been brought up a lot um both in terms of like how it plays into the future of the protocol, how it introduces like a new primitive almost uh by like imposing some constraints. Um and also like it was like ranked quite high uh in terms of how crucial it is uh for the protocol in the future um by a lot of teams and researchers uh which was always I mean which is always nice

to see. Now the question is also like how integrates with other like upgrades as always but like still overall like very positive sentiment I guess and um so you'll see like probably quite a lot of different things pop up in the next few days. Uh one just did like a few minutes ago. So I'm going to start with this. Um yeah, first of all uh want to announce uh with Barnabas tweet that there is a new protocol research call uh that we are going to try out and it's the pilot is going to be u on April April 2nd. Uh and the like this kind of new protocol research call will probably

serve as like a focal point for researchers and devs to try and clarify the network's goals and and what we want to focus on uh in from like the research perspective I guess but like very close close to the protocol still uh in the next month years and more. Um, so I think like it's going to be structured as approaching a few very crucial core questions we need to address uh as researchers and devs and more generally as the community. Um, and the first call is going to focus on local building and the future of local block building. I

think it's a it's a super interesting topic and it actually links a ton with Fossil. So if you read the post um you'll see like fossil basically mentioned everywhere because the TLDDR is well I've yeah I've said this like a few times but there is quite strong argument that fossil can help with scaling but not in like the usual way of like just like increasing the gas limit or um or like any other like sort of parameter change. um but like rather because it sort of serves as a very very important first step to relieve local blog builders of the duty of upholding

censorship resistance for the network. So yeah, the TLDDR is that today we do heavily quite heavily rely on local blog builders um to include transactions that are censored by the more like sophisticated large meth boost block builders. Um and so we sort of like I mean implicitly rely on them to contribute to improve the network's CR properties. Uh I know Tony has been working on on this also lately and you also have like MEB boost builder that are including sensor transactions. So they're not the only ones contributing to the network's censorship resistance

but they do play a role today. And so while when we introduce Fossil, we basically create a new role so which is participating as an includer and that role is like specifically tailored to contributing to censorship resistance. And so this means um it's a first step so we don't have to rely on local blog builders for censorship resistance. And so I mean there are other considerations about livveness and one also like very important part is like um to actually have a robust sensorship resistant mechanism mechanism for blobs as well which is I think a very very high

priority if we want to make that argument. But once we have this, we can basically confidently say that local builders can now um outsource that their block production to external map boost builders um and earn more revenue because now by doing local block building basically they they earn a lot less than just by using metusk. Um so and they can do that like guiltfree because they know like the fossil or like the includers will be responsible for CR now. Um and so yeah um if we yeah and for will impose constraints on the

you know external sophistic sophisticated block builders which is not the case today. Um so if we do that um that means we can basically now impose higher maybe bandwidth or hardware requirements on the builders that are like supposed to be uh sophisticated maybe um and um this is a good argument for for scaling. So that's like the TLDDR. I think the post uh of Barnaby goes obviously much more in the into the details. uh if you have time to read it uh that would be great also to have your feedback and and also have you guys attend the the the research uh the new research protocol

research call will be will be very nice um I don't know if there are any questions uh on this per se uh otherwise we can move done. Okay, nice. So if we have no question that means everyone agrees for can be a good candidate for for scaling which is great. Um I guess next on the agenda is is more like focusing around um implementation progress. I know there has been a lot of work and back and

forth uh on rebasing Fossil on Electra. Uh so and I I know Jiun wanted to discuss this. Uh maybe that's a good place to start and but yeah, I know like a lot of you guys have actually like tried to work that out. Yes. So thank you for bringing me up. So last time we uh agreed to rebase on the electra because uh if blue if pure doesn't merge then we're going to have problem with it. So we want to just get independent from it. And since then I've been working on rebasing prism onto

Electra. The PR is still on review. So the test is not complete yet but behavior wise I think it's usableish but please be aware that there might be some known bug and so with that we are trying to work on the CL interrupt between Prism and load store. I think we can also use lighthouse as well. But another thing I want to discuss is using EIP7805 in the E. So get currently uses Osaka which is tied to flu but now that we are based at Electra I think we could use Prague or EIP7854 in the E. So I want to ask what other

people think about this. Yeah. Does anyone have any thoughts? Like I guess this is more directed to E people. Uh okay. Terren says yes, but like do you think we should actually try and get EL people to weigh in on this or like is everyone pretty much okay with doing that?

Sorry, you saying to base it on Osaka? Um currently that's what um I've done. Yes. But the thing is ethereum package the curtosis set osaka time only when flu fork is set. So so we want we don't want to set flu fork because that's the whole point of rebasing onto electra. So I currently just updated get image that doesn't check any fork version so that we can just uh test the cl inter based on electra but this is like a stop. So I just want to know what people want to do

with this fork check condition like do we want to uh based on a proc time or do we want to use EIP7805 fork just like how we do in the CL or I or if there is no EKS here then maybe we can just uh delay making a decision and then we can just use um E that doesn't check fork condition so that yeah we can just moving on making CL interrupt.

So so okay so if I understand correctly the option is either um Ozaka Prague or like a 7 805 or right? Yes. Unless we can somehow modify curtosis so that to set osaka time when there is eB7 805 fork is set but not blue fork is set. Okay. Okay. And so what's yeah what's the cleanest thing you think we should do?

I think we need to gain some feedback from a devops team regarding this because they know better about modifying curtosis. Um but with um yeah if we are talking about just like a very near future like just couple of weeks then we can just omit the work condition for the sake of CL interrupt but I think we need a we need we want to make a decision about this sooner or later.

Um I guess if we if we use the Petra time stamp we'll have no check and that would mean that we'd have to keep it on a separate branch as well. Whereas if it was in its own fork or Osaka then you know it could just be merged into master and not be activated which might be a bit more uh convenient. Yeah. So I think I can ask Perry or Phelip regarding this and then Okay. Okay. That sounds good. Maybe says

maybe EIP75 7 805 fork uh will be nice. Uh yeah, let's let's maybe delay this decision and I can also chime in and try to see what DevOps thinks if that helps. Um are there any other progress uh on the implementation side of things like what's Yeah, I I was traveling quite a lot so I' I've followed a bit less closely. So if anyone has like any updates on where they are or any blockers that would be now would be a

great time to to chime in. Yeah, I can give an update for uh from Tu side. Um basically I started running some local interrop with Prism. I had some issues with this uh photo of fork thing but thanks to Jhon Jihon I got some help and it's working now. Um I noticed some issues on de though uh interacting with the E. Uh so I'm trying to debug that and fix it. And once I have a a working version, I'll probably try to publish a uh a docker image so other clients can also run interact with teo.

Nice. Awesome. And yeah, the issues you're mentioning are more like specific. Um yeah, somehow um because actually in teu we don't have anything photo related. So at the beginning with the initial uh curtosis config when we reached fulu tech like crashes and uh doesn't like that but now since jihon published some uh get um a get image and a new genesis generator that uh kind of uh just uh goes from electra to AIP uh 7805 fork it's working now so yeah we can say that it's it's specific Okay, great. Okay, nice. Yeah, but I

mean it's still linked to in this Yeah, sort of rebasing on the on the right fork, which makes sense. I think like the whole idea behind like not trying to rebase on fulu uh was to avoid like dealing with the complexity of like the changes that are going to happen there. So yeah, I mean I also think it makes sense to have like electra and then rebase into uh a fork that's EIP75 785 specific. I think that makes sense. But yeah, great. Thanks a lot for the updates.

Uh does anyone else have updates? I can maybe quickly talk about load. So we haven't really done major code changes in like the last weeks. I think mostly ONC just joined I guess. Yeah. But uh it's mostly what NC I think already told in the in the op channel like there seems to be still a mismatch in the state but besides that I think we are good. Um, one implementation question I had is regarding uh seconds per slot because I saw a lot of curtosis configs modify this value but it currently breaks how we handle the timing parameters because the these are part of the config and uh

basically hardcoded in the config. For example, the cutoff for updating the inclusion list on the execution layer is like at 9 seconds. But if you have 6 seconds per slot, then this is in the next slot, right? So curious how others handle this. In TGO for example, we we we calculate that at runtime. So we get the new values from the config and then we end up having new values. So yeah, it's it unirectly changes those cut off and freeze time, I guess.

But as I Okay. But if it's defined as part of the config as it currently is in the spec, I think this is not something you can do, right? Or at least we we are not doing that anywhere so far as far as I know. So I think I mean my suggestion previously was to move them completely out of the config and just have them handled in a similar way like in fork choice where we have the a tester deadline at 4 seconds which is always calculated on the fly. I guess what you mentioned uh based on seconds per uh did you want to say something?

So I guess the question is should we update the spec maybe or Yeah. Yeah. I think there's room for like spec improvements on that cuz I think if we change it to 6 seconds per slot then everything will fail because of it's currently it's hardcoded basically. Do you know why it has been specked out in that way? Because seems like function of the slot per second anyway. Yeah, it's just oversight of the spec. We haven't really found much about that.

Okay. Okay. So the way sorry the way for one I guess to update the space. Yes. to be precise updated this batch such that it considers that the seconds per slot could be uh essentially um not a function of 12 seconds. It could be like 6 seconds or even it could be 4 seconds. Okay, great. Thanks.

Does it answer the the question? Yeah. Yeah. I think yeah, the main thing is though like Yeah. I guess if that's the case, we need to move it out of config as far as I understand it. But I think that's anyway good because having these timing parameters in config or even preset uh sounds like bad because in the future if you want to reduce seconds per slot on mainet for example this is like an additional blocker then or something you need to adapt more values so it's not good I think. Yeah.

Yeah that makes sense. Although yeah. Yeah. Arguably like if the slot times actually get shorter, we'll need to make sure like the timings still work anyways. But yeah, I mean in principle for sure that makes sense. Okay, great. Jun, I think I saw a thumbs up, but uh does it work for you too? Yeah, I just wanted to make sure that I understood it correctly because last time we talked about this. I thought that we were we agreed to go with hardcoded value to making it not break.

Um but now it seems like modifying improving the spec so that it can be more flexible sounds better. So yeah, I think I'm good with this. Okay, nice. Great. Um, anything else? Any new updates from maybe other clients? Um, another mind. Um, I've kind of fixed the uh remaining like spec changes.

Um, so specifically about um adding that new RPC endpoint uh because I had to kind of change the way the the payload was built a bit because I I didn't realize that at first that the inclusion list wasn't necessarily uh doesn't necessarily arrive in the fork choice but can arrive later. Um so I've got that working. Um, and now I should have a bit more time to uh do some kind of finish things off and and test some like interrupt. Okay. Do you mean so what do you mean by the inclusion list arriving later than the for choice?

Um, so in the original spec, um, we had the inclusion list as part of the fork choice updated handler. um whereas now it's in a separate um RPC endpoint which is like something like update to include inclusion list. I can't remember the exact name. Um so whereas before I was assuming that when you get the fork choice you have the inclusion list it turns out that you actually get this fork choice and then later you have to update once the inclusion list arrives.

Okay. Okay. I see. Okay. Great. Nice. Okay. And that's so that's fixed. So now it's all about like trying to interrupt as well. Yeah. Yeah. I have a bit of time now so I can work on trying to test that out. Okay. Awesome. Great. Thanks. Uh okay. This is nice. And Ethan, I think you unmuted for a bit. Yeah. Um Lighthouse wise, it's not too big of an update, but um we've rebased also on top of Electra. Um, we've added the occlusion list uh beacon chain events to be compatible with cryptosis again and we're hopefully ready to continue to try interoping with other

CLS again. Nice. Okay, great. Awesome. Any any other updates? Anyone else? No. Okay. So I mean it's kind of nice. It feels like like everyone is sort of converging towards like the same stage somehow. Um where it's all about like actually trying to make it work and interact with each other which is very nice. Um if most of the like client specific issues have been answered and now it's all about like collaboration

then um this is good. Um are there any like is there anything we can do to actually like make that work? Like is there like some like meta things we can ask? I guess some of this will actually depend on the DevOps team, but like is there anything else we can do to make the cross like the interrupt between CL's and ELS work better? Like are there are there like any specific things? Uh or is it more about like trying things out and running with it?

I actually discovered a weird behavior on G uh regarding the engine API. Um so um so for example like um if I recall the fork choice updated and then afterwards I immediately called uh engine get inclusion list G might return a empty inclusion list because it might not be ready uh it's still processing uh um the latest payload.

So I need to manually wait for like four seconds before calling get inclusion list in order to get like actual content from GU. I don't know if that's a intended behavior. I think I need to look into the implementation again or can I get back to you offline? Yeah. or at least um if if the EL is not ready to return inclusion list instead of returning an empty response, we might uh want to define like error code or like some special response like uh the status is syncing or something

uh so that like we know um you know EO is not ready instead of uh returning an empty response. Um, one thing with the testing environment is that there might be the case that there is actually no transaction in the man pool. Um, so so your idea is it would be better to distinguish it might be better to set an empty case as a some special case like syncing or something else, right? Yeah, that there should be like some distin like there should be some distinction uh between the two

scenarios. Yeah, just so so if there is no transaction at all then it should return just an empty list but if there if E is in sync then you want to get some specific response of that, right? Yeah. Gotcha. Okay, cool. Yeah, that makes sense. Um, so I guess looking into this for the GU implementation.

Uh, I've also talked to people in the the GU team recently and they said like they are like willing to help a bit more with the the PR. So, I can um I can get back to you to to you on this as well. Um I mean, they're obviously busy with like other stuff now, but but still like I think they're like willing to to help a bit more. Um great. Uh and then yeah, I did want to also maybe get a small update on the metrics side cuz I'm started to be a bit interested on that as well. um like what are the metrics that are going to be very useful

to use uh to track how fossil is doing? Um so do do you have any updates Katya or otherwise I can just like give some give it some more thoughts and like come come back to you guys with something a bit more concrete. Yeah. Where where I stuck is to run my local image and this is where I need June's help I guess. So because when I use his images uh it works. I can run curtosis uh but I still don't see inclusion lists uh tab. Uh but when I build my own uh prism image u it doesn't work. I have

missed blocks. So um probably I will DMG hoon and I need to solve this because I have a dashboard but uh I build it blindless. So, um, I need to check it before I open the PR. Oh, yeah. This is Okay. Okay, that makes sense. Great. Great. Thanks, Jon. Yeah. Um, yeah, I might do that as well like very soon too, so we can also sync on like the metrics we we want to to see and which ones are maybe the most uh interesting to keep track of.

Um, that's a good idea. we can collaborate on. Yeah. Okay. Great. Nice. And then yeah, I guess as always like on the testing front, I guess that that's going to come a bit later. I don't think more work has been done the testing side, right? I Oh, I did contact the uh what is it? steel team at DF which is mostly involved in um the testing uh for anything EA related and they said they are like happy to help. Um I know yeah I mean most of the work has

been uh like we haven't really gone into testing much but like is anyone from the E side interested in like maybe joining the group with the steel and like starting to open a PR and like get moving in terms of getting their help on on testing there. They're like really good. They just basically said, "Yes, we can dedicate some times, but we need someone um that's accountable for like opening the PR so we can actually get the give you the the help you need.

After I finish working on a rebasing pism onto Electra, I can spend my time there if if it works. Okay. Yeah, that's awesome. Um, thanks. And then in the meantime, if like any of the E guys uh is interested in in joining and and like after you guys are like done with like the the stuff you are doing right now, um please let me know and I can just like add you to the group and then uh we'll start working with the the the steep team on the E side. Unfortunately, we don't really have like an equivalent of a testing team on the CL side, but uh but yeah.

Yeah, man. Oops. I just meant to click thumbs up. Sorry. But yeah, I'll reach out to you once sort of ready to start testing with them. Okay, perfect. Yeah, that sounds good. I I'll also like uh yeah, if you guys are not ready, I can also like mention it uh another time. But um I think it's nice to have people that are dedicated to testing and willing to to help. So, I don't I didn't want to miss it or lose the momentum there. Um, cool. Uh, and then yeah, I think also wanted to get out if like does anyone else have anything to

say or or any updates before I like go on uh on my rambling? Sorry, I probably missed something, but I don't see the link for the call in this post. Uh, is it there or not? Uh, let me check. I opened the issue, so it's my fault if it's not there. Let me see. Ah, well, it's in the issue I opened probably

like the zoom link for the goal, isn't it? I opened it like three hours ago. So it's it's very recent but like this should Could you share the link to the issue? Oh this one. Oh yeah. Okay. Thank you. Uh yeah, I'll puja also said that it would be very nice to have a bit of uh more time uh of me posting the the issue and the agenda.

So I I'll do that as well like trying to do it at least like 24 hours before. Yes, Mercy. Sorry, I think Nintendo should go on cuz my is going to fall. Um hi everyone. Um we've been working on a tool to visualize the meool. Uh this is just um an update uh to inform you that there's some work happening. Um we had commented on let me see we had commented on the agenda for today.

Uh that's where you you'll be able to find most of the details for the tool here. But yeah, generally this is just to inform the team that we have something currently ongoing. Um and this is also needed. The original um team that I started working with was the Earth Panda Ops and um yeah um now working with Marci she brought it into the she told me that also the fossil teams uh need it. So I'd appreciate any feedback uh or any um contributions that we can get on

that. Thank you. Okay. Thanks. Oh yeah. Uh how how does it interact with with fossil per se? Is is it literally just a mele visualizer? Sorry, can you repeat that? What's how does it interact with fossil per say? Like is there like a specific link to to fossil or is it a tool more generally to visualize the mele?

Yeah. So it's um it's meant to be a ktosis package that provides a visual a UI for visualizing different uh transactions from different uh nodes specifically clients. Um yeah, from the description the project the original project idea it seems that um it was really meant to help in also checking things like uh different uh different rules that apply to different clients. Uh so yeah, I think it's kind of linked

from that perspective where you we could be able to tell different um rules that work for acceptance rules that work for different clients as well. So I think that's where the link with for sale comes in here. Okay. Interesting. Yeah, we could basically visualize like the transaction characteristics like how long it's been pending there or like its priority fees and everything and based on that also check like um if the transactions are included by nodes using a specific PL client according to the rules that client has determined which is pretty

nice. Is that what you what you refer to? Nice. Okay. Yeah, that's great. Um so maybe now it's also about like highlighting visually uh like making sure like the characteristic like the features or like the characteristics of the transaction we care about are visually uh there in the in the tool you're building which which will be which will be very nice. Um nice thanks a lot.

Yeah. Um kindly if you because one of the things we are having trouble with including the earth panda ops team is just what how to visualize you know the UI when you when you open that link what do you see what kind of uh interface interactions or uh transactions do you need to see so if you have any idea on how you want that to work or very specific use cases kindly just uh help us out with that and uh we should be start we should start working on the front end sometime in the next uh couple of weeks but if anyone has any ideas contributions

just kindly drop them um open an issue we'll appreciate that thanks nice okay that makes sense I mean I think yeah related to Jiun's question is like what is a very obvious uh answer in the fossil call is like yes, do we have a tool that is able to basically visualize inclusion lists like all of them per slot? Um and then within inclusion list like the transactions and the correct characteristics and how um they were like I mean every transaction per inclusion list I guess and then like compare that to uh what transactions

were included in the actual payload. So, uh, it feels like that's the most obvious question we care about on on the fossil end, and it would be extremely nice to be able to visualize that in a in a nice way. Um, so yeah, if you have ideas or want to discuss this, uh, also feel free to reach out or maybe write in the discord channel or or directly to to me. Um, happy to help. Yeah, that's super helpful. Um, if you have any more use cases, definitely I'll reach out as well if I need any

clarifications. Thank you. Sounds good. Uh, anyone else uh wanted to add something? If not, yeah, just wanted to to signal on on the more, I guess, research side. I'm going to try and spend a bit more time starting now or like in the next few weeks really digging into what good censorship resistance mechanism looks like for uh blobs. So if anyone wants to help on more you know research but like

still very close to protocol development. So if anyone has ideas or like designs or mechanisms or like has even like thought about it quite a bit um I would love to collaborate and get insights or or feedback from any one of you on what what you think it should look like. Do we even need to look at something that's very close to foral for blobs or can we just like go with a very different designs just because it's a very different um kind of transaction with very different assumptions. Um so if you guys have ideas or want to to work on this I just wanted to signal like that's something that's going to be

quite uh a lot on my mind in the next few weeks. Um and uh yeah um just just wanted to signal that uh I will also like I mean as I make progress and and write stuff and collaborate with people I'll just like keep you posted but like I I think like basically as I said before like if you want to make the argument ah we can fossil can help scaling and we can like basically not rely on local blog builders anymore. uh we need to find extremely strong censorship resistant mechanisms for bloods and uh for livveness. Um so these are like crucial crucial things if we

want to like make the argument for soul helps for scaling and yeah I think we should as a yeah guess core devs or researchers or community or whatever like it would be nice to have a bit more focus on this because it's not been researched too much uh until now. Um but yeah, if uh uh if that's all, we can probably code it for now. Um thanks everyone again for attending. I I'm planning Okay, I'm I'm going to say it.

So I actually commit to it like I think next uh for call I want to make it a bit more, you know, have a speaker and have like an actual presentation from someone. Um uh so I'll I'll try to to to do that and and make the next fossil call a bit more organized and and nice. Uh but yeah, thanks everyone for being here and um see you next time. Thank you. Good morning.