FOCIL Breakout #14

Transcript

[Music] Um, I don't have that many updates on the research side of things, I would say. Um, yeah, maybe I can just give an impression of where I think Fossil is in terms of positioning relative to Glamsterdam and its inclusion there. Um yeah, so I I feel like there has been quite a lot of uh conversation around slot restructuring or slot shortening.

Um and the TLDDR is that for soul is like in basically compatible with both. I think in terms of yeah practicality it would be very hard to combine forol with something like shorter slot times if my understanding is correct because shorter slot times is quite a big undertaking um and might require to also like reach out to a lot of different actors throughout the space. So it wouldn't like necessarily like fit too well in terms of yeah complexity and time needed to implement both.

Um I think there is a different that's a bit of a different argument for for the situation in which forol is combined with the slot restructuring uh EIP like you know it could be PBS it could be delayed execution could be yeah probably one of the two. Um I think there there might be a bit more space for for Soul to also sort of like uh fit in uh in the in the same fog. But let's uh let's see how it it goes. The official sort of deadline for proposing headliners for Glamsterdam is now over.

And now I think like the period of like discussions around, you know, what should go into Glamsterdam as a headliner and maybe like not as a headliner um is supposed to really kickstart now. Um, so yeah, just small update on this. Um, I do encourage you to like uh well, we're not that many in the call, but like if you do have, you know, thoughts or like opinions on whether Fossil fits with like slot restructuring or slot shortening EIPs.

Um, if you think there is like some urgency around fossil being included um in Glamsterdam rather than later on. Uh please just like speak up and and and and maybe like talk about it. Um yeah um yeah as I said earlier I think there is not much controversy around fossil being important but there is a lot of different opinions on whether fossil should be included like in Glamsterdam. I think that's like the most contentious sport. So yeah that was just a small update. Uh does anyone have questions on the more I I guess like

high level fork inclusion topic. Okay. If not uh let's get into yeah implementation updates. U maybe do you want to share what you just added in the chat? Yeah, sure. Um, yeah, I was referring to the um, we have two spec PRs uh, raised by Jiune and there is a discussion in there. I guess we can discuss that. So, basically the um, consensus spec one is about how should we handle the uh, inclusion list um cuz

initially we put them in the store and then we decided to do some changes and it looks like we didn't reach consensus there. So, Yeah, I know Mikail has um a different different view on that. So maybe we can discuss that. Yeah, for sure. So what are the two main options? So basically initially we we put the inclusion list in the store uh and we spec that uh but now we have a new PR to to um to remove that from the store and uh uh as far if I'm not correct the last change was to uh introduce an inclusion

list store and uh I don't know if um everybody agrees on that. So yeah, I to be honest, I don't have a strong opinion. I in in TEU I've implemented it the um the way it was initially, which means I put the inclusion list in the store. I know other clients implemented it differently. Uh but I think we we need to uh to make a decision on that point. Okay. Yeah, that sounds good. Does anyone have strong opinions then on so I guess it's like putting putting it in like a general sort of like generic

store uh versus creating a new store that is specific for inclusion list is in that right? Yeah, we can summarize it that way. Okay. Yeah. Yeah, if you have thoughts uh me h yeah I I'm sorry if there is a noise in my background. I was just going to speak about the spec. Um and yeah, it probably makes sense to do after implementation updates.

Uh what do you mean? Okay. I mean are we doing implementation updates now? No, we can just dive in. Uh that's like that's part of the implementation uh discussion. Okay. Yeah, there aren't really implementation detail. We we're basically since few weeks now we are working on the um improving the spec and uh so yeah, I think we can dive in directly. Okay. So, uh I don't have a a strong opinion about whether it should be inclusion list store um a separate thing to the future store or not. Uh what I was going to speak about is the um the

state transition and uh actually specifying how CL and E are communicated uh in the state transition function. I think that uh historically and it makes a lot of sense to me uh we've been trying to abstract away from uh the particular CL communication mechanism and uh we have a separate spec for it which is the engine API specification. Um so I think it as from that standpoint it doesn't make sense to to actually put the way the ACL and the L communicates it to state transition uh which is basically what the current

uh PR suggests to do. Um so I think that uh yeah my point is basically that uh including list satisfiability doesn't have anything to related directly to the state transition itself. So the result of the state transition will not be affected by whether E is satisfied or not. And uh I think it's uh yeah it should be uh separate separated from the state transition and uh we can do it in like when if we if we want if we don't want to introduce a separate uh call to the execution engine to the spec we can just abstract uh this check away by

introducing an abstract function similar to retrieve blobs retrieve data blobs as we have today. We can just introduce something like is inclusion list satisfied and pass a payload inclusion list to it something like that in the fork choice. Uh I mean in the fork choice in the own block handler. So this is kind of like my line of thoughts. Uh I guess the problem with that though is that it kind of leaves the spec a bit ambiguous. No. Or would this be defined elsewhere like very clearly?

Uh it it it leaves this back abstract. Yes, you're correct. No, it's not going to be defined anywhere else. Yeah, it's tough. Why? I mean, it's not exactly simple, is it? like it it would be beneficial to spec this out so that it's not like an unknown. Uh what's so you don't have to what what exactly do you want to stick out uh the interaction between the yield and the seal essentially uh but like the inclusion was satisfy or

like I don't know I guess uh consensus spec is about the specification of the consensus uh layer protocol it's not about uh a CL communication we have a separate spec for that because we have a particular uh CL communication mechanism which is the engine API that we use today so I don't think it makes sense to put this uh communication into the back and enshrine the particular way of communicating this to this back um what exactly are you proposing we remove from the PR are like uh

yeah I idea ideally we should uh keep state transition untouched because it's not changed it's it's not affected by the inclusion list checked if there is a strong push for um enshrining the ELCL communication into center state transition then I think we should remove this function and pass the or maybe not I mean like Not not not remove but replace. To be clear, which function are you talking about? Are you talking about get inclusion list transactions?

No, I'm talking about state transition itself. It's it's almost it's almost a function now. Uh almost because yeah anyway so it's a function now and uh yeah we should pass inclusion lists into it uh explicitly. Specifically, which function? Sorry, I guess I'm just confused at this point. Are you talking about? So, we have on block. Yeah. Or no, we have a state transition in the PR.

It has access to inclusion list store. It reads inclusion list from that store, right? and then do does and then passes them to E the then then the state transition does not do anything uh about the result of uh E satisfiability check right uh I do not know you mean in the spec or in the actual implementation I mean in the spec In the spec it checks if it return any error but then this check um is not surface to

any other part of the spec right what do you mean I mean that the result is used maybe I'm confused you know so if it's return any error then it yeah the CL tries to reorgate And that happens in onblock functions, right? But the spec does not say anything about how this information is uh passed from the state transition to the onb block. Right? Or it does. It does it it it wraps a state transition in the try catch and if it's it it tries

to catch if it returns um invalid inclusion list error. Oh, I see. So I think this is a question about what is the right level of abstraction. So like for other people who are not familiar with this discussion uh let me add some yeah thank you Miy let me add some uh share some context. So uh um so what I want to ask people here and maybe other devs especially CL devs is

about like what would be the best way to write the ail validation in the CL spec. The actual client implementation is the CL passes if the IL's when calling the new payload engine API and then the E validates if the given payload satisfies the IL constraints after transaction execution and before withdrawal processing. So this is not a post state is some kind of a state um in between like a intermediary state during the state transition. This is because of some some possible edge case. So anyway and if it fails to satisfy I constraints the e returns an error and then cl for

its parent. So in the spec uh currently it is this part corresponds to process execution payload in state transition function and currently this is how the PR is written at the moment. uh but the feedback is from the CL's perspective as Mikai said uh the EL state is out of concern. So instead of modifying process execution payload function to pass I is in the new payload call um if I understood correctly and then we just use like an abstract call for example is inclusionally satisfied in on block function and if the result

is false then CL tries to reorgate and my question is what if like this deviates from the actual implementation more than we want. So of course we want good abstraction but like I think the question is how much do we tolerate the the deviation from the actual implementation and this is also related to whether we want to use fork choice store or enclosure store because um the reason why I didn't try to include uh put uh the inclus storage and second um in my mind uh in the spec we want to use um process

execution payload function to pass and this is happening on the beacon chain layer not for choice store layer. So if you put in the fork choice store then the bitcoin chain should have an access to fork choice store and this changes like whole lot of function signatures and this is too invasive and looking at other example like blob also affects on fork choice algorithm but we don't put it in fork choice store we use abstract function call to uh retrieve blob data so that's um that's why I removed it from fork store but there was another comment that it's looks like a

little bit of under specification so that's why I included enclosure store and what it does is just basically specifying how that kind of uh incl um behaves when it receives inclusion payload function when it tries to fetch the enclosure list and pass it to the EL. So to summarize like I think we have like three options. One is going with the current implementation.

Uh the second is just like what Mik suggested. We just remove all the changes in the state transition and use the uh is inclusionally satisfied abstract engine API call in on block. And the third option is we just pass in the new payload call as is today. But instead of checking it like if state transition returns an error or we just use the ab abstract function which is is enclosurally satisfied to fetch the result from the e.

So yeah, this is how I view it. But um maybe we might not able to reach to consensus because well we don't have enough dev I guess but yeah. Okay. Uh does anyone have an opinion about this? Uh what do you guys I mean Justin maybe uh what I was just thinking that this the latter two options we wouldn't be wouldn't be able to do as much testing

correct for inclusion lists like if it's an abstract function um I think we need to monkey patch it then it would be possible but yeah so currently what I what I've done in my local uh chain change is we didn't have enclosure list store so we just uh bi patch the retrieve enclosure list transactions um but I think I we can multi patch enclosure store as well so yeah so it's it's I think it's just a matter of decision so I'm not sure how that we I'm not sure how we would do that for like the reference tests though like we would

have to ask clients to monkey patch to write if I'm understanding that correctly Um, do you remember how we monkey patch test blobs? Because they also use a retrieve blob and proof as a monkey patch function. Yeah, I don't know. I don't I just don't think we have tests for that or I don't remember. All right. Or we just I don't know. I don't remember. Sorry. No worries. I also don't remember. Maybe we can just um add the testing format to yield include a list so that uh client can consume that testing vectors.

Yeah, maybe. Yeah, I'll I'll just say that I don't really have a strong opinion on any of this. whatever is simple and uh well speced or like clearly speced. Yeah. Well, I'm not a dev, but uh I do think like in some ways I do introduce uh a new primitive on the protocol like it it it doesn't really exist now that like some actors constrain others especially like that

the CL sort of like for choice is affected by a very E ele heavy sort of feature of having transactions included in a block or not. Um so it makes sense that it it will break some of the super clean abstraction we are trying to keep in some ways. Um I don't think there is like any fundamental way around that just because it's it's very core to the proposal right like this sort of like interaction between the CL and DEL is uh is really

yeah core to to what Fossil is and what inclusion lists are. Um so no if that I don't know if like uh there is a clean simple way to do that uh great uh if there is one way that allows for more testing than others I maybe tend to lean that way just because we will need quite a lot of of testing for for I think um yeah but it I mean it does feel like an implementation sort of like choice that is not like extremely that is going to be like very hard to

motivate uh strongly. So yeah, do you have other like sort of I mean you said you didn't have strong opinions but like uh did your opinion sort of evolve or do you still think the same mig? Um on the testing side I think that uh we can only expect uh so we we are speaking about uh consensus layer testing rep tests. So the uh there are two possible um there are two possible outcomes of the E satisfaction check. It either

satisfied or not. I think we cannot go beyond this level of abstraction anyway. And uh we'll just have to yield this in the um in the spec test and uh with uh the high level of abstraction from the CL communication it's it's possible. I don't have any strong opinion on using the abstract function is inclusionally satisfied.

but I have an opinion that if we were to use new payload call to pass the IS then the CL spec is better to specify it in that way. So I am okay if we don't check if the state transition function call returns an error or not. It give us better but the engine API call I mean the new payload call is better to follow the actual implementation but I think it would be the CL devs who um can make a better decision.

Yeah, but if we do this introduce this dependency into this spec, then the state transition function should have should get the inclusion list from from somewhere, right? Yes. And isn't it the same if we were to just use is inclusionally satisfied function only? Uh you mean like you Yeah, you want to put enclosure list in the pro choice and then just pass it. Yeah, I'm I'm just saying that if uh we want uh so my opinion is that if we want for some reason to uh make inclusion list a part of notifying your payload

call then it should rather be explicitly passed uh to the state transition and the result of uh this check should be explicitly returned by the state transition function uh not by an error like it is done today because it's too pythonic but by some um protocol logic rather than some Python logic. So it's like state transition becomes uh a new function which is actually two-state transition and check inclusion list satisfiability.

uh it accepts inclusion lists explicitly as a parameter and it also returns a not only the modified state as it is as it does today but also returns the result of the inclusion list check then this check can be used as is now in the PR by the unblock but I I disagree with this uh um let's find it this way but if there is a strong push uh for you know pass and L uh to notify new payload in the consensus layers fact and we can do it this way.

Okay. Okay. So you if I understand correctly one of the push back is also on how the inclusion. Yeah. I mean I I think I agree with the general idea of not trying to sort of make it implicit that is it is like modifying the fork choice in in some way like because it effect effectively is um and I don't I don't really have a problem with like having you know the IL satisfiability as a an explicit input.

uh into the fork choice function. Um and also that like the sort of like vote or not vote is conditioned by whether the IL condition is satisfied. Um yeah, I wouldn't mind having that instead of just that error popping off. Um, I'm I'm wondering whether like other people have opinions on this, but like at at least intuitively I I see why it's maybe a bit nicer to have it explicitly defined.

I mean, if we explicitly try to change transition function that we have to change all the function signatures from state transition down to uh process execution payload. And I think that's invasive changes. And looking at how clients are implemented, they don't they use their own way to cach in collision list and fetch it somehow. They don't change state transition functions. Okay. So you think it's it's bas basically it's better to contain the validity of the payload on the E side. And so all the CL has to know is whether the

the payload is is sort of like returns an error or not rather than changing all the you know state transition related functions because that is how it is implemented and for me I may be biased because I I know how both the CL and EL are implement. mented. So for me that's much easier to read and comprehend but I also understand that there is another separate spec for you know the specific CL and communication so we want to use that abstraction.

Uh so yeah but like I my I'm of the opinion that u making it explicit is a is a bit too in invasive. Yeah. Okay. I see. Uh right then. Yeah, I mean if it if it introduces a lot of complexity on the CL side of things because you actually do need to change a lot of things for uh if you want to explicitly change to the fork choice then yeah maybe I go back on what I was saying before. I I feel like yeah, maybe we need to balance like simplicity of implementing the the

actual thing we want to implement and and the conceptual abstraction of what it actually does because I agree like that yeah conceptually like it does actually change the fork choice like we can't we can't really go around that but if it makes it much easier to constrain changes to the E in terms of like payload and whether it like it's valid basically or not um rather than having to to change like the whole state transaction function and and and whether like to vote or not for a block. I feel like I

would be leaning that way, but uh it's uh it's hard for me to comment too much on it also because I feel like I've been talking a lot but I don't usually I'm not a cord. So maybe I can u you know try to summarize all the discussions we had here and then um I can I can leave that as a comment in the PR so that everyone can take a look into it and I don't think we have to make a decision today so we can

invite more core devs to take a look into it and then provide some feedback. Uh yeah. So like I'm also okay with like avoiding the if the state transition returns an error or not because it I feel like that's somehow mixing the CLNL communication too much but like yeah I think we are just circling back to the same question like what is what kind of a what is the right level of abstraction we want But I guess we are lacking of CL deaths here. But yes, Mikai.

Yeah, I just wanted to add uh maybe this kind of like uh summarize my thoughts on it uh for today. I agree that we should not make any decision may not make any decision today. We have time. I just wanted to emphasize that uh if we think that this um check should be explicit. Uh the inclusion list is explicitly passed as a parameter. The result is and we are thinking that this is going to be an invasive change.

um then we should think that is the implicit way of doing it also invasive. Why why can't we just change the semantics of the state transition? It's not only the interface. The interface is easy to to change. Uh but it's only the it's also the semantics of the function. So we add one more semantics to to the state transition in the spec which is from the spec standpoint um is not is not good and should be justified very well to my opinion.

So that that's just it. Yeah. Can you like just so I'm I'm sure I'm I understand what you're saying is like yeah if we imagine we contain like the the issue of having to change the whole for choice function by just like like conceptually or like returning an error of like saying h the payload is is valid or is invalid and so it's like basically you either explicitly add like a a parameter and like another sort

of input to the forchoice function or you add an invalidity condition to the payload on the E side. Um, and you are saying both are like in invasive. Uh, is that is that what you're saying? Is like basically you you I mean you still have differences in terms of how how hard it's going to be to implement on the both on the CL and ES side.

No, I'm just uh yeah, I'm saying that uh if we can't for some reason uh make this check explicit in the state transition, not in the fork choice, in the state transition. Yeah. If for and and the reason is that it is invasive. Uh so we we should I I don't see the difference between implicitly doing it and explicitly doing the same thing. So but explicit explicitly doing it just you know highlights us that these changes in ways I'm just trying to try to uh explain why I I think it's a you know it's it's a wrong way to modify state transition in this case we know that this change is like um you know

um yeah because it's too invasive for me it's it's too invasive it's very invasive for the state transition to have some specifics about how CL and DL communicate. Yeah, I can watch what you have one question for you. So whether we change function signatures or not, if we decide to use new payload engine API call to pass the IS do you still think that we should not specify in the spec? Oh, I I think with that we should make it explicit like path ile to state transition and return the u not the error not by doing doing it by handling

the error by catching the error because it it becomes a spec right so it becomes a um a logic a spec logic so it should be written in a not not in the python way you know uh but it should rather be written in the spec logic way so like a more I don't know I I I probably don't know uh right words how to express this. Okay. Yeah. Well, I feel like there are two things but correct me if I'm wrong.

One is you are saying that it is a complex change that is and whether it's explicit and implicit like it actually does uh change the fork choice. I mean I think that's true but like I think most of people that have been working on fossil are like really probably assuming that it's worth adding this complexity and change to the protocol because it gives uh a lot. So I think there is a trade-off there that I mean yeah um you know every most protocol upgrades will bring some added complexity um and then if the trade-off is like in the favor of h but that added complexity

will actually give us something we really care about then it's it's probably worth doing. Um, and then the the second very different thing you're saying is like you don't like the Pythonic way of expressing of like just like a you know having like an error expressed uh to to like uh surface the fact that uh the uh payload didn't satisfy the inclusion list. Uh and that's yeah I mean that's very that's two very very different questions to me. I think the second one uh is worth maybe trying to express it

in in a different way. U for the first one if it's just a more general comment about like ah it actually brings some complexity into the protocol um and you're not sure it out way outweighs the benefits of having for in the first place. Um yeah we we can definitely have that discussion but it's it's a very different one. Yeah. And and and the third concern is that uh we are going to introduce something to the state transition function that does not have anything to deal with the the state transition itself. I mean it does not affect the result of the state transition function and that's the problem. So we are just

adding an additional semantics to this function. Um there there are actually two functions in one. This is how this spec works today. This why my uh other concern. Yeah. But I think yeah let's just stop here and probably if anyone yeah if if if this discussion will be relevant uh we can continue next time or you know at sometime after.

Yeah sounds good. Okay. Um and if uh we can also ask like the opinion of uh some other people I guess. Uh yeah, if I mean Ji Hun, you said you were okay to do that. If we can summarize things and maybe post it in the PR, but also like post it on the IL or like inclusion list uh discord chat so people can have a look and sort of like comment on this. I think might be useful to just have a bit more visibility on this. Um uh yeah. Does that sound good?

Yeah. Um I can I'm just happy that we just like use this time to um bring our thoughts on the table and see like what kind of options are ahead of us and um yeah I can of course like share the uh no no I really appreciate your feedback and uh yeah please just yeah and uh yeah thank you for you're providing feedback and Um uh let me share the summarize in the in the discord maybe so that if my summarize is wrong or off then please just uh leave a comment there so we can have a um better

summarize bit uh a summary before you know asking other core devs for or feedback. So yeah yeah sounds great. Um cool. Uh okay. So are there other like items that people wanted to talk about other than than this? Actually I have it's a it's a short one. Uh so in the beginning medi shared two PRs. One is a CL spec and the other is a execution API spec.

Um, so in the execution API spec, I'd like to change to use fork choice updated instead of update payload inclusion list. It's because inclusion list are part of payload building process and it seems there is no strong objection to overloading payload attributes. So I've been asking people about like what would be better uh engine API uh last week and then this is the conclusion that I got.

So and so using fork choice updated seems semantically better. The CL can call for choice is updated for example at the beginning of the slot with without enclosure list and then it can call it again with enclosure list after the proposer's enclosure is cut off and right I'm sorry keep just using our time but lastly um this is also Mik's feedback I think we should introduce IL broadcast deadline at 12 seconds into the slot to avoid So it's split view by uh IL equivocation. So let's consider this scenario. A proposer proposes a block at 12 seconds into the into the

slot and the block doesn't satisfy some IIL. then 50% of our testers vote for its parent but some IL committee equivocates that I and let's say the rest of our testers recognize this equivocation and exclude that IIL during IL validation so they vote for that block so although this is uh this might be a rare edge case um introducing I broadcast deadline at 12 seconds into the slot uh will avoid this tester split view before and after their attestation. uh because we do not re-evaluate IL validation even if we

have um I equipocation after a tester finish their attestation right okay and you're saying we don't have an explicit like sort of like deadline at 12 seconds now right we don't have it do we no I don't think we do yeah you're you're right yeah okay yeah so just adding Yeah, that that actually sounds good. Uh but maybe good to also write it down so more people can give inputs. Uh it does make sense to me like uh yeah, we should have a sort of like end timer.

but uh yeah uh if you have a chance to just write down like in it doesn't have to be like sort of like fleshed out but just like the give you like write down the idea and so we can just uh uh add it to the spec then I think that would be quite useful right then let me share that uh summaries of two thing u by tomorrow. Yeah. Yeah. No, sounds good. Uh, great. Uh, no, thanks for sharing. That's useful. Uh, okay. Maybe a more general high level comment to finish is like I think it's nice to

like really sort of hash down details and sort of like discuss exactly how the the spec should should look like but I feel like it's going to be done anyways when or if let's say fossil gets cified Um, one thing that I sort of grafted in in some chat, so it's it's a bit informal I think, but is that there might be some like additional constraints on EIP um if they don't come with like specs spec tests. Um, so I think it would be important to also sort of like

have some um doesn't have to be exhaustive. it doesn't have to, you know, cover all the crazy weird edge cases, but I think it would be nice to also sort of push on this soonish because yeah, we are like basically in the middle of like of discussions around whether to to include uh EIPs or not. Uh so if that is a factor, I think uh it would be nice to have like spec test and sort of like be ahead of the curve. Although I don't know how we are, just to be clear, we are publishing spec tests, reference tests for fossil EIP 7805. Correct.

Well, wait, what are they? Uh, there are I mean it's mostly like the the standard suite of tests to be clear. I don't believe there are any uh specific like inclusionless tests yet. Yeah. Okay. Yeah. Okay. Nice. Okay. Good. Good to know. Yeah. I I had in mind like the sort of like yeah trying to test some even basics basing test around like inclusion list per se of or or what can happen or I don't know you know equivocation and stuff like this or do we have time to pro propagate um different objects in time are the deadlines set correctly all of these questions are like I think there are

like we we we got ourselves like some really big margin so I think we I will say but I yeah just saying it would be nice to sort of have some tests around run that specifically but I I agree and that'll be quite a lot that that's fine. Yeah. Uh okay cool. Uh and uh yeah that being said I think like some other UIPs like are not even close to being even like spect or defined or specified. So we I we shouldn't like take this too crazily uh I don't know I don't think it would be like a a super hard requirement but

just like sort of like nice to keep in mind. Yeah, Jun. Right. So, I just wanted to ask you about um how much coverage test coverage we want because we our spec is changing. So, and that affects on how the spec test should be written. Um but I can write tests that are not affected by the changing spec and would it be okay? Yeah, I think we should start by having these tests in any case like maybe that's a good way to think about it. I think like two maybe dimensions are important. The one is like we want to test like very obvious failure cases

like we don't want to necessarily get into like the super weird edge cases now and like we want to test uh things that are less likely to change uh given like the spec considerations. Um yeah if we can have some tests that fit well with those two dimensions I think that would be good enough. Uh so yeah. Okay. So I think the test we can have today would be something not related to the changing part which would be uh which is related related to inclusion list committee and the kind of stuff and since we are currently discussing where to put inclusion list and so on. So that

can that part cannot be tested unfortunately. Yeah. Okay. Yeah. Yeah. We can we can start with that. I think it's fine. Uh um I I just don't want Yeah. I just don't want to like block things because the spec might change. Like I feel like in any case the spec will probably change like once a lot of people look at it and like try to implement it in in and like try to actually work on it very seriously. uh for like future forks. Um but yeah, let's let's definitely start with like test that wouldn't be affected

by this and then we can just like check back in a couple of weeks or something. Yeah, sounds great. So I I will just um unload the uh spec test that I already made and I will just move on to the EL spec while we are discussing the CL spec. Okay, awesome. Yeah, that sounds great. Thanks. Um, cool. Anything else from anyone else? Okay. Well, thanks a lot for coming and uh see you all um online. Bye-bye.

What's up? Jesus. Heat up

here. Heat. Heat. Heat.