FOCIL Breakout #15

Transcript

[Music] Um, thanks for joining us. Hello everyone. Welcome to the 15th Boss breakout. Um, Tom is here but he cannot stay longer. So I will be running this breakout. Um, so I want to share few updates. Yeah, thank you Tom. uh I want to share a few things related to colmsterdam and then we can move to uh implementation updates and then if anything else uh that I haven't added to the agenda we can also talk about them firstly as many of us here might already know you can express your preferences of

the headliner for climate forecast uh here's a link and at the ACD the call. We briefly talked about the headliner for Clamsterdam and we realized we want to have more opinions from client teams and the community. So, please make a vote and let it be heard via Discord, Twitter or as it calls. Uh here's another link you might want to share your preferences.

I also want to re-emphasize why we need fossil even though the censorship today has gotten better. We are seeing less censorship because top builders are not censoring for whatever reason. But Ethereum is vulnerable to censorship threat if top builders were to turn on their censorship again. Not censoring and can censoring are fundamentally different. Ethereum censorship resistance can be swayed by the opinions of a few.

Fossil is not a penencia but it does improve censorship resistance by far. So glamster dime is probably a good fork to ship censorship resistance and we can still ship other proposals that that scale L1 L2 and improve UX. Lastly, let me share an update regarding EPBS and fossil compatibility. Uh we have a new article written by Toma. Uh with EPBS is being updated by Potos. The compatibility between EPBS and Fossil is also revisited. The article provides the up-to-date ideas about the compatibility. It uses the IL

bit list. is a bit list indicates the IS that a builder considered when building a block. If I were to provide a clunky summary of it, please feel free to jump in to if I'm making some wrong explanation. Um a testers validate if a payload for previous slot satisfy the IL constraints and check if the IL bit list of a beacon block for current slot is a supererset of their subjective IL view. In this way we can leverage the whole beacon committee or the IL list inclusivity check but al alternatively we can decide to let PDC perform it.

This allows us to reorg payload instead of a beacon block when it fails the inclusivity check. While this give us better livveness or we going to rely on PTC instead of the whole pick on committee for the inclusivity check. Um so it boils down to the tradeoff. For more details please take a look into the article. Um, next up is implementation updates. Before we jump into it, uh, does anyone have any questions or comments?

I guess we're good. Uh, so let me just continue. I guess the implementation updates will be mostly about back but please feel free to jump in and share if you have any other updates. Um so in the previous breakout call we discussed about how to specify the sales spec. Afterward I shared a write up that explains what were the problems and what are the possible solutions. Thanks to detailed feedback from Mikail, Justin and Medi, we were able to find a much better way to write a spec. So now the PR has updated and now I'm working on the EL spec in the meantime. I guess people will be busy with other stuff

like Fusaka, but can we have more eyes on the PR and margin if it's okay? Um, let me share the link to the PR in the chat. Um, yeah. So, merging it into the into into this main branch would allow me to resume my work on the CS spec. So, yes, Justin. >> Uh, yeah, I would love to get this merged in soon, too. >> Thank you. Uh, I'll give it a proper review today and then maybe wait for to give his review and then merge.

Or is that too? >> Yeah. Okay. Yeah. So, uh that's all from my end. Um does anyone have any other updates, thoughts, comments, or feedback? I guess today's breakout is quite nice and neat. Um, maybe Tom, you want to say

something? Otherwise you can just you know call it a day and then uh see each other after two weeks. All right. So in the chat Thomas says um curious to hear if people have opinions on fossil and glimpser dam. So uh in a Twitter we are seeing people are expressing their preferences on what should be the headliner for

Clemsterdam and they are you know uh putting EIPs in different ranks from S to D. Some people put fossil on S, some people put it on D. Um can we have some you know uh ask people here about what their preference is. Right. server, >> right? And it would be valuable if you

could let us know if you don't think that fossil should be shipped in Glamsterdam then I'm curious curious to learn why um because yeah is it because of the proposal itself or is because you know like it touches so many things from CL to EL or is it because of a priority priority as in the three goals of the EF scale L1 L2 and improve UF X or whatnot. Uh, I have a dumb question. Fork cast isn't like an official voting mechanism though, right? Like it doesn't track

anything. You're just like you would share the screenshot on Twitter or something. Or is there a better way? Okay, it's not cool. It would be nice if there were some more formal voting mechanism or it was like public another time.

Okay, I I'm in a spot where I can talk a bit. Um but um yeah, I think I think there are pros and and and against uh official voting mechanisms and that would necessarily like need a buy in from most of the people and like a whole sort of like rethinking around. I think the STL list is more yeah informal way of stating pref preferences. Um that is a bit more fun and nice but yeah shouldn't be considered like a like an actual thing. I think it's still nice to share and just because even for me, you know, I've been less involved in other proposals and just like trying to look at STL

list, it actually forced me to to look more into the some of the other ones I like didn't know much about which was nice. Um but uh but yeah, shouldn't be taken very very seriously. Fair point. ACD calls are the official channel if I'm not wrong. Yeah, exactly.

>> Yes. And yeah, maybe to reformulate also the question, I just wonder if like anyone here has concerns about the mechanism or if it's just a matter of priority and urgency into including stuff uh uh rather than fossil because if if it's if it's the former I would love to know so we can maybe try to work on it. If it's the latter, then there's probably not a ton of work to do on the proposal or mechanism itself. It's it's just like a matter of preference and and urgency.

Okay. So I I will take it as not Okay. Cool. Uh yeah, if anyone has ideas about like uh things they think are wrong with the proposal, like let me know. There was some a bit of turbulence on Twitter today because um the Max Resnik who is now at Enza and Solana he he's a bit known to be like vocal on Twitter, but he was saying that it adds latency to the critical path um because of the view merge mechanism. I think like that's I mean the idea is partially right and but the the time it's like the actual latency itself like can be

reduced down to less for sure if uh we we think it's like um completely safe to reduce that latency between like basically the view freeze um for the testers and and um and the proposal. Um but yeah, I think my thinking is like let's start with like good safety margins and then look at how it behaves on on test net and mainet and maybe then reduce it down. Um I really don't think it's like it's like a crucial point that we um should take like at heart but it's uh it's still interesting to to hear it and and think about how and whether and when

we can reduce that that latency. But is it correct to make an argument in that way because inclusion leads is not the only way I mean not the only channel to include transactions. >> Yeah, for sure. No, no, no. I I think it's it's not I think it's one additional channel. So yeah, it doesn't you know it doesn't reduce anything for transactions that don't go through that mechanism. Um, so yeah, that's a that's a good point. Um, and yeah, uh, I I think it's really nice

to also like look at the fossil and and shorter slot times. I'm also I also agree with Justin. I think it's safer to reduce slot times after fossil is included. uh just because like reducing you know slot time can sort sort of like shorten some deadlines uh that we currently have in the protocol. So like we sort of like reduce safety margins in a way. Um and yeah, I mean my my take and I know it's not shared by everyone but like I feel like it's nice to have like a good slot structure we like before we shorten slot times uh rather than doing it the other

way around. Uh but that's just my preference. Um I I think I'm like open to do it myself, but like if everyone else like wants to do it, they're welcome to. But like sort of do, you know, fossil and shorten shorter slot times compatibility post just like I did with EP EPBS and fossil might be useful. Um but the yeah the overall point is like no it's not incompatible and um yeah um I mean at one point it you know especially if we go to six basically

like going to six is not incompatible with fossil like if we go to yeah two or three then of course like there is this sort of like view merge mechanism that like adds some latency see that can't be compressed down to zero. Um, but yeah. Uh, yeah. So, when we talk about shorter SL times, are we talking about six seconds?

Yeah, maybe even less than six seconds. >> Okay. >> On the long run. >> Right. Right. Right. I mean if you go down and down and down then yes there will be some some like tension between false and like you know one second slot time I think for sure. But then we need to rearchitecture like the whole consensus mechanism anyways like the whole there needs to be so much more of a restructuring that what we are thinking about right now that it's even hard to exactly grasp how that will play out. Um and fossil will be one of the things we have to rethink if we want to go to like one second slot time but for six I don't I actually don't don't think there's any

incompatibility there. Hey, so can we say that even if we go to six which is the most plausible uh approach then we we can still have fossil working on mainet and we don't have to restructure anything in that case. >> Yeah. Yeah. I think I I can write the argument more like nicely but yeah I I really don't think there is any tension with like six seconds time and for all for sure. Um because I mean I building and broadcasting is literally done in parallel uh at the same time as like block building. So it it yeah it doesn't

really conflict with anything else. >> Thanks. But yeah, I do have a feeling that this question will be asked uh a lot and maybe we want to write something about it so it's it's more clear and we we can also like get our feedback and and opinions from from you guys.

>> Yeah. Maybe it would be good to have some quantitative experiments. >> Yeah. Yeah. Yeah. For sure. Um, you mean with like the time it takes for stations to propagate and and like things like this or like >> Yeah. Yeah. Exactly. >> Okay. Yeah. I mean, for sure. And that's it's nice because this effort is anyways sort of like done because it needs to be done for shorter slot times in any case. So, we can just take advantage of this and and and see how well it uh it fits with with Fossil. Uh yeah again I don't think it will conflict.

Yeah, I I think the the most important parameters for such an experimentation would be uh slot times and number of inclusion lists and see where is the the maximum right so where the the setting the the optimal setting saturates after we reach that optimum >> right yeah so one thing that's important to still keep in mind I guess is like that uh inclusion lists with by by definition always be much smaller than the block size. Um so yeah I I I doubt they will ever be the bottleneck because yeah the the there is also like a current thinking

that we won't necessarily want or need to include like increase the inclusion list size as we increase the gas limit for blocks. That's not like that doesn't actually have to go together. So you can like and and the the goal is like you know if we actually get to decouple local block building from um solo stakers then we could actually like sort of increase the delta between inclusion lists and um the the throughput of the chain um so like the gas limit for blocks basically um yeah and so yeah just saying like basically I don't think we should

necessarily scale the scale the IS scale the the block uh uh like the gas and that then it will become even less of a bottleneck compared to like broadcasting full blocks. Yeah. number of just sorry Kya just number of includers matters and the size of the inclusion list matters a lot as well. Um now it's it's meant to basically have all inclusion list. So the 16 be the size of the size of one blob. Um that was like sort of like the

thinking around the size. But both do matter and both can be changed. um even though we don't think like it's going to be a strain on the network right now. Um yeah, Kaja. >> Uh yeah, hello. So I'm currently working on the metrics we discussed in Berlin in drop uh and probably will publish a draft uh today or tomorrow. So we will see the picture like the size of ELS, the number of ELS and potentially it could help like to evaluate um the six slot.

Yeah, six second slot. I hope it will help. So we will soon see it on loadar and maybe other teams will join. >> Yeah, that's that's awesome. That's like exactly what we need to start gathering metrics and start like making choices accordingly. Um so it's >> so so my plan is to add uh the dashboard to Cal Corttosis. So every client which has the same metrics will be able to use the dashboard. So um yeah maybe by by the next call I hope yeah we'll have some results.

>> Nice. Yeah that that would be really really awesome. Thanks. Okay. Um, does anyone have anything else to say? Sorry to I actually have to to run, but uh it was it was fun to discuss this. Just before we maybe close off, uh, Otus is asking in the inclusion list chat if

we went over, uh, the doc about the EPBS and fossil compatibility. So Jiun gave a good overview but uh maybe next time I can actually go and present it a bit more if people are interested. Um because I feel like maybe it's nicer if like I send it in advance and say there will be a presentation so everyone has time to just like read it and and know about the the doc. Does that sound like an okay idea?

>> Yes, sounds awesome. So, uh yeah, so we, you know, did this kind of uh research updates in our prior calls and maybe it's good time to revisit the compatibility between the PBS and fossil. Um I have a question. Is that article fully reviewed? Um I have a question about some sentences. So uh I wonder if it's like fully reviewed by uh people who working on both a PBS and fossil.

Uh so Terren and Potus both had a look. Um I mean it doesn't mean that they you know looked extremely into the details of everything and for me same like there could be still mistakes in there. If you want to give feedback like you can either just like post on on it magicians or reach out to me or or start discussions in discord like any any way is fine. Um and if yeah if you spotted some like things that were like inaccurate or maybe that needed some more like uh some better wording just uh for sure let us know.

>> Gotcha. I want to, you know, um, dig deep into EPBS and fossil. So, uh, let me reach out to you sometime, uh, in this week or next week. Thank you. >> Yeah, that sounds great. Awesome. Um, cool. >> All right. If that was all for everyone, maybe we can keep this one short. What do you think? >> Yep. uh we can just see each other two weeks later and thanks everyone joining and thanks Tom for um staying with the call. Uh so uh yeah thank you everyone.

>> Thanks everyone. Bye bye. >> Thank you. Bye for everyone.