FOCIL Breakout #16

Transcript

So how does the anatomy look like in a post EPBS and fossil world? Uh this is the the short answer. It looks really really nice because the two actually fit quite well together. Uh the slightly longer answer is what we are going to get into into the in this presentation. Okay. So um slot anatomy um like the this like what happens in slot n minus one is actually like very very easy for you guys to sort of grasp um because uh it's fossil like so yeah you you'll notice I'll talk about like different

parts of what's happening in different slots uh in like the first diagram I'm going to show but um but still like here we can just talk about what what fossil So imagine in slot n minus one you have the includers right and they build and they broadcast their inclusion list on the CLP2P network. Um and yeah just like fossil normal fossil uh towards the end of the slot the testers of slot N will freeze their views and stop storing new inclusion lists and then a couple of seconds later the builder and the proposer actually um also stop storing new IS and what the builder does is like it

updates its execution payload to make sure it satisfies conditions and I conditions like you all know are like the union of transactions across all inclusion lists are included in the payload unless uh the block is full. Okay, so let's say that's what happened in slot minus one. Of course, like duties and stuff are actually overlapping over the duration of of one slot, but I thought it would be easier to actually go through it this way. Um, okay. So, yeah, the rest uh of it happens in slot N. So there is a bunch of things. Um, one thing that happens is that the proposer uh will first just like run its for choice rule to

basically determine the valid parent block to build and um that determination depends or like incorporate the PTC vote outcome for um the slot n minus one payload um which basically determine whether the payload of slot n minus one was made available on time. Um and then the proposer will just like select and broadcast a beacon block that he has selected from a builder. Um and the selection will basically depend on on like a bunch of things. Now um uh first uh it will depend on of course

like the builder's bid like the actual value specified in the you know payload header like you want to choose the highest one like that's uh that's exactly like how it happened to how it happens today. Um it also depends on whether the IL bit list includes all the IL that are seen by the proposer until its uh own like freeze deadline. So that's a new object like that's a new field that is included in the beacon block. And so the IL bit list is basically allowing to have builders include and commit to a list of the IL they have seen and taken into account to

build their payloads. And this is this is basically very very nice because it allows proposers to select blocks from builders based on the IL bit list inclusivity let's say and inclusivity means whether the builder's IL bit list covers all inclusion lists that are stored by the proposer before its freeze deadline. Um okay so hopefully that makes sense. Um because then based on the IL bit this basically the testers or the PTC of slot N we'll see like that it can be both like there are two possibilities of design there can condition their votes based on the IL bit list inclusivity. Um but yeah we can

come back to this because there is like a special sort of like split enforcement slide but hopefully that's clear. Um, does anyone have questions on on the IL bit list or is it all good? Okay. Um, so then yeah, the testers uh of slot N then we'll basically vote for the beacon block n um again depending on like a bunch of conditions. Um the first condition is like the blog builds on like a valid head according to the attesttor's view of the fork choice. Um and the fork choice rule actually

incorporates again like the PTC votes from slot n minus one. Um then another condition is like the payload for slot minus one actually satisfies its own conditions. So yeah, if the payload from slot minus one basically wasn't compliant. So like it didn't include valid inclusion list transactions in its block um the testers of slot n will not vote for block n uh because they want to like reorg the non-compliant payload n minus one. So that's like another important condition and that's sort of like the you know the second part of the split enforcement.

The first part part being like the IL bit list um part that I just talked about before. Um and then the last part is I mean there is a DA check too uh and the last part is the actual IL bit list uh for uh the beacon block N. So the IL bit list in the block. Yeah, that's if the testers are actually doing that check like as I said like it could be done by the PTC2 but ifers are doing that check like exactly like in the diagram then the bit list in the block has to include all the the tester was aware of uh at its own freeze deadline um and yeah again it can be done by the

PTC2 uh and we'll go over like the difference there okay so that's for the testers orange sort of like column there. Um okay and then the builder will reveal its full like payload n and that can be done you know at any time but maybe a rule of thumb could be uh for example after having seen enough as destations for the beacon block included including its payload header u that's not like enforced or anything it's just like a rule that could be used um but there are I mean especially now there's a lot more into into this like um and we can

actually discuss the free option problem if you guys want uh later on. Um and then the PTC um votes for payload payload n uh if the payload n is made available on time by the builder. So now we have the whole like sort of like slot structure for EPBS and fossil and you see that the only thing that's added as a field is really that I bit list in the beacon block n which is not much and then you know you need to add a check for that bit list of course um and and that's like the first part of the

split enforcement and then the second part is like the X slots at testers uh will actually like you know verify if transactions are actually included in the in the payload and if there are um you know if there are like some missing transactions were they were they missing because they were invalid or were they missing because I don't know the the builder was censoring or something. Um, yes, Mark. >> So, um, does the PTC need to check if the the list was respected when it votes on whether or not the payload was available?

>> Yeah. So, there is that's like basically the design choice we have and I will get into it later. It's like either done by the testers of slot or by the PTC. It can be both. Okay. Yes. Potus. No, neither of them would. I mean, if I understood Mark's question is about checking whether or not it was satisfied. Neither of them would actually check this. They only need to check >> if the if the bits include the bits that they needed to that they had at their own view and freeze time.

>> Yes. Yes. Yeah. Sorry that that I didn't like misunderstood the questions like the full enforcement is only done by the testers of the next slot. Um and the IL bit list inclusivity check can be done by either the attesttors of slot N or the BTC of slot N. Does that make sense? >> Um yeah. Okay. So, so in this case if it wasn't so it needs to be done also by the of course the proposer slot end. If the proposer builds um let's say on a so if the proposer builds on you know the payload being available but the

payload didn't respect the IL list the idea is that the testers will reorg that beacon block. >> Yeah. >> And then if >> But they'll reorg that beacon block but not the previous beacon block. They it'll just be an empty >> Yeah. Exactly. I see. Okay. Um Okay, cool. Uh right now uh yeah on this like different diagram then I like I actually added like every duty that could be um that has to be done uh for different reasons uh in a given slot. Um and so okay so the full line duties are the

ones that are like existing already. uh the like larger dashed boxes are EPBS related and the you know smaller dashed boxes are fossil related. Um and so you can see that there is overlap between duties. But what's nice and we'll get into this later is like um that like the the order in which um these duties happen doesn't really matter as long as um you don't require to be built on the latest head for them to be considered enforcable. Um so yeah that's like one thing to remember because it's important

uh and I will come back to it later anyways. Um yeah, so that's exactly what I was saying basically. So the the first sort of like consideration is order independence. So yeah, since we don't require to be built on the sort of canonical latest head on the of the chain to be considered enforcable like um then you know the order of these duties especially like towards the end doesn't really sort of matter much but it's like still sort of like important I think to say that we would ideally want you know most of the

to be built on the the latest head. So the ideal scenario will be to have a payload that is released um before uh the the the IS can be built. That's like that would be actually ideal because it just means you have like freshest fresher is uh so inclusion list and and that's just like better otherwise you'll have sorry you'll have a lot of different um uh yeah you'll have a lot of different uh transactions that can like that will have been included in the in the latest

block. So you'll have like a bit of yeah you'll have transactions in the IS that are like not as fresh as they should be and then that makes the a bit less effective. So I think it's still important to aim for having a payload released before um uh the IS are built but since it's like not an enforced thing like it actually doesn't really matter much um and so that's that would have been like the biggest I think tension between for and EPBS and it turns out like it it's not really one um so yeah that's uh about order independence Um and then yeah the the the I mean

that's the whole split I enforcement thing I already talked about quite about it quite a bit but like yeah um we we can do like the split eye enforcement and we can basically require builders to you know include and commit to the IL bit list in their blocks uh to indicate which I which inclusion lists were considered when constru constructing their payloads and it's nice because yeah it allows proposers to select blocks based on the IL bit list inclusivity check. And so as I said um based on the IL bit list the testers or the BTC of slot end can condition their votes based on uh the inclusivity check.

Um and so that vote basically provides like an early useful but yeah of course a bit included because you don't go and do like the actual full check about all transactions. Uh but it it does provide like a very useful signal to the proposer regarding whether the builder's payload considered like all the it should have been it should have considered. Um so yeah so you can do it two ways like either you actually use the attesters of slot N. So yeah the testers will just like verify whether the IL bit list matches their local frozen view before attesting. And so the primary

advantage of doing it this way is like of course like it leverages the entire beacon community and not a subset of it with the PTC. But it does mean that you can reorg a beacon block just because it fails to satisfy the IL bit list inclusive check. Um so I mean Franchesco didn't seem to think it was as clean. Um but yeah I think like both are actually like variable options. So let me go through the PTC option. Um so you can have the yeah at testers like don't perform that check uh the inclusivity check I mean and then the PTC vote

actually does it and so this approach like is a bit cleaner like in terms of abstraction like actually well just like from one angle I guess um because it protects like the beacon chain from being reorged due to conditions basically um and so the beacon block will no longer be rejected just for containing a commitment to a payload with the that fails like the inclusivity check of the IL bit list and instead like yeah if the builder's final payload fails the actual you know final determin deterministic post checks then only the payload is real which is nice. Um, but

you know the main trade-off there is that the initial inclusivity signal relies on like a smaller set of validators in a BTC rather than the entire tester committee. So we'll need to make a choice there. Like I don't I I've thought a bit about this and I still don't have like super strong opinions. So um I mean if you guys have any let me know. Um, yeah. >> Um, I believe another consequence might be that even if the PTC voted against the payload that in theory the next proposer could still build upon it. I I'm not 100% on that. Maybe pus could shed light. But

>> what does it mean to vote against the payload? Oh well to vote against the payload being available and respecting the inclusion list. You rely on the PTC for that if we go with the PTC option of enforcing the the IIL. But my understanding I could be wrong was that it it is still possible for a proposer to vote that a payload is available even if the PDC said it wasn't. >> Yeah, that's that's absolutely correct.

If the payload is available then the proposer can build on top of it and a testers will take their block because they can check that it was available. >> Right? So then a consequence of moving the PTC um enforcement to the to the PT or I'm sorry that I enforcement to the PTC committee is that in theory it could still make it in the chain even if it didn't respect the inclusion list. No, it can't because attesters do make the full enforcement.

>> Yeah, >> the payload does not respect the IL. The attesters for slot N will not vote on the peon block of N that was based on that payload because that payload could not even be in their for choice. >> Okay. I thought we were talking about a trade-off between enforcing it via the testers at the next slot or the PTC of the >> No, no, no, no, no. again like the so that's why it's split um and so the full enforcement will always be done by like the next slot attesters um and what we are talking about in terms of like should the PTC or the tester of slot 10 do it is only the IL bit list inclusivity check which is just

like a signal uh for the proposer but doesn't you know uh it doesn't actually change what the adesters of slot N will will do on the next slot. Yes, photos. >> I think an easy way to explain this is that um both this bit list either like being on the testers or on the PTC, they're not enforcing anything. >> They're just signaling and it depends on to whom they are signaling uh if you put them on the testers or on the PTC. uh you're always signaling to the next proposer that the payload that they might need to build on did satisfy or not it did not satisfy their their view

of our choice. So the proposer already has some information that otherwise wouldn't have but also it it might if you put it earlier on the testers the builder themselves they know already that their their um their build their payload was already invalid from the start. >> Yeah. I'm not sure if that information is useful or not, but it it's information there, but it's only a signal. It's not enforcement. The only enforcement happens in the next slot by your testers. Yeah. And the and the difference is like I mean the other only difference is like the PTC vote only affects the payload while the tester vote affects like the gun block.

All right. Um, okay. I think it's one of the last slides, but yeah. Uh so I think yeah TLDR is like like the key synergy I think between Fossil and EPBS revolves around the separation of the beacon block and the execution payload because that separation basically enables to enforce IL conditions by rejecting non-compliant payloads without affecting the beacon chain stability. Um and I think yeah I I I think I agree to butus but uh um this is I think like a a big improvement over other proposals like

delayed execution um just because you don't need to add you know um the static static checks uh that come with uh block level access lists to make false and and and delayed execution work. So I think that that's a very big sort of like that's like to me that's the most important synergy between the two proposals. Um and so yeah again you know um since um without like that separation you could have like a weird situation.

Um and so like a non-compliant block. So yeah, imagine without the separation you have like this weird scenario like you can have like a non-compliant blank non-compliant block sorry that will initially receive like the full support in slot n but once you discover it's like non-compliant because it just like fails conditions then the next proposer of slot n plus one can attempt to reorg this block with a competing block and so basically this will lead to like two blocks uh so the original non-compliant block and the competing compliant blank having equal full weight and that's just like a very weird situation to be in. Um

and so we with the separation of course we we don't have this uh another advantage of like cleanly separating uh I mean yeah no the that I I was going to say like it it it does get rid of the static checks and that's sort of uh nice that you don't need like a way to get um the the post state values uh to uh through BS like through block level access. This like cuz you actually yeah that payload um execut block execution payload separation gives you this already which is sort of uh very nice at

le um and yeah I think that was basically it. There is a bit more in the post if you want to check it out but uh but yeah we can also discuss more. Yes, but >> yeah. So, one of my worries is on the timing. Could you say a little bit like could you spell out how are the timings before the start of the slot? Because the the problem is that you need to have a testers freezing their view uh the IEL proposers uh sending their their IELS.

But also I mean we know that in real life most bids that will contain this uh this bit list will happen after the start of the slot but those bits that are um over the P2P chain they need to start before the start of the slot. So I think the protocol needs to if we ever unless we just ditch completely the P2P side we're going to have to have that freeze before the start of the slot to give time to builders to actually build and broadcast their bit list before the start of the slot. So how does what are the numbers that you have in your mind?

Uh okay. So maybe here you mean so what's the contentious one part you you're talking about like because >> the one part I was worried about is like the you know re releasing the payload before building the IL. That's like one we should be careful of. >> No. So that that I'm happy if if we don't have like fresh i that doesn't seem like a big problem to me. Now the the problem that I see on on tight deadlines, especially if we go to shorter slots, >> yeah, >> is that uh the builder for the next slot needs to build the payload before the

start of the next slot. >> Mhm. >> Uh so so the start of the of the of that build process needs to happen before second zero. >> Okay. And that builder already needs so that time needs to be after the deadline freeze for uh testers. >> Yes. >> And it should have a buffer that is long enough so that that builder can actually include all of the IIL bits that every >> Yeah. Okay. So yeah. So I mean that was the case in for as well. you need like that bit of a leeway between so you have the attesttor deadline and then you have the proposer or let's say builder

deadline and there needs to be a bit of a delay um between the builder freeze and the start of the slot. So today it's 1 second. Um I think it's like yeah based on what I've seen it's like it takes like about 100 to 200 milliseconds max to build a block uh today by like performance builders maybe. Yeah I think I think like locally local builders could actually like do that quite fast too. Um it's also not completely you know rebuilding uh the the whole block because it's it's making sure to add the IL transactions you you can add but like

it it's not like some sort of weird complex me strategy uh ordering um so you can like maybe estimate like that with like a big margin of error on like u I don't know like 500 millconds or something and then delete to broadcast like to send send the bits and the blocks to the proposer and the proposer needs to to to pick one. Yeah, I was I I definitely had like the 12 second slots in mind. Uh if we go to six, I mean I still think you can have quite a tight deadline between the builder freeze and the moment it has to

broadcast its block and bids. Um and then you know there are going to be timing gains but those are like uh expected uh so if you have timing gains in a way like you gain some time at the beginning of next slots but it's it depends on the size of the payload of course and a bunch of other things. Uh yes Mark so there's yeah so we have two deadlines here a local freeze deadline and proposal. So I assume the local IIL is for the attesters.

>> And then the idea that the proposer is really more for the builder. >> Yeah. Yeah. >> Okay. And >> well it's also for the proposer because the proposer still has to you know check the builder's IL bit list and only accept if it's like with their view. >> Oh, I see. Okay. And then and so um and the gap there is very similar to like the NEV burn gap essentially is what is the way I understand I don't know if you that's that's kind of how me burn works as well where you >> Yeah. Yeah. Yeah. You have this sort of like two like deadlines as well for for you you need to to have that. Yeah. and

and and so so it's the job of the proposer to propose a block that they believe satisfies the local aisle freeze deadline so that the attesttors will vote for it. Um >> and yeah, the concern here is about having enough time. I mean we could presumably how far back can we push both of these deadlines? Like what's the furthest back that we could push them?

>> You mean uh like back in time? >> Back into the slot. Yeah. >> Uh yeah, I think then uh you actually so the the the earlier you have to build your IIL then the less fresh it will be compared to like the release of the payload. So that's one one thing we we have to care about. But you know, let's imagine we have a deadline for releasing the payload early in the slot, then that it also maybe like solves a bunch of these concerns.

Um, and yeah, I mean, we could push it quite far back. I actually agree because like you know, building an IL is like a very unsophisticated process and then you need to broadcast like 16 objects. Uh, like it's not a big deal like it will be quite fast. So like here like it's kind of misleading like having this much time dedicated to like building and broadcasting IS that could be pushed like way far like way like a lot a lot more a lot earlier let's say >> well so but it sounded like you said you need you need knowledge of the post state to some or at least the beacon block of that

>> yeah ideally the payload of that slot before you can broadcast an inclusion list >> I mean you you don't That's that was like one of the main thing like you don't have to. It's just better to have fresher transactions in IS but like you don't you don't need to. >> Oh okay. Like you can still make an I with like you know transactions that are not as fresh and that were included in the slot that you were in and it's fine like that this this should be still like enforceable and valid and everything.

>> Okay. So yeah, then we probably have quite a bit of headroom even in the worst case. Okay. >> Yeah, exactly. >> Yeah. So, um the the the builder freeze that Terren said that it was just one second before the end of the slot. Now, that's absolutely fine. Now, I don't think you can make it much lower. Uh I mean, it's it's never going to be a proportion of the slot. you have this this fixed latency which is bit propagation and bit propagation doesn't need to come before the start of the slot >> because even though you can count with timing games honest proposers will choose the bid at second zero and we'll

just send the message at second zero >> so I don't think you can make it much slower than 1 second because you need bid propagation and 1 second of six second slots becomes um much tighter >> than what it is today So yeah, I'm just wary about the the sixcond slots uh idea with regards to this. >> I agree. I think the we we'll have to see I think but but it's true that it's incompressible time basically like so the time between the proposer I and the start of the next slot is like fixed latency you can get rid of and then the local freeze deadline relative to the

proposal I freeze deadline is also fixed latency because you know you need to have some wiggle room um to make sure the proposer like doesn't by accident like um not see I he's supposed to see and like more than half of the testers actually see an IL that he he didn't. So if he's not that well connected like you need to allow some time there. Yeah, we fixed it like I I think it's like 9 and 11. So it's like 2 seconds. Maybe that's actually too high. Like maybe you don't need two seconds to have like a to make sure like a proposer will have seen all the worry about that part of the propagation. The other part is the one

that I'm worried from 11 to zero. >> Okay. So yeah, but you know like if you can have like one second and still keep that 1 second and then maybe reduce like the difference between the tester deadline and the proposals to like 1 second as well then it's 2 seconds. I don't know. Yeah, we we need to to see. I haven't I want to like maybe write something later about like the the the the sort of like you know what happens in the six second slots. Uh but but yeah, we'll we'll have to see.

All right. Does anyone have uh other questions? Yeah. >> So there is one more deadline actually the is submission deadline which is 8 seconds into the slot. So I think it's better to frame this in um so a testers have one more one second to gather the IS over the PIP network while builders have two more seconds to gather it rather than they have one second buffer for gathering the full I list.

>> And I also have a >> Yeah. Sorry, go ahead. >> No, no. I I mean, yeah, those are like questions are just like a bit hard to answer before we have benchmarks. I I think the but I agree like we I don't know if I actually don't know if it's going to be like 2 seconds, one second like will we have time? My guess is like broadcasting I like propagation time for like 16 small objects like should be fast hopefully. Uh maybe we'll need to adjust the P2P network for this but like at least with 12 second slot times like we have so much room. Um and then yes you have this all these data you you basically need to to tune but yeah you

had a second point I think. Sorry. >> Yeah. Yeah. What what I'm talking about is not about the estimated I broadcast time. I'm just talking about like timeline wise. I think it's better to say that uh the builder has two more seconds to gel than testers and >> okay >> yeah I I have one question but I guess pot want to say something related to this so I guess I can go next so yeah please go ahead. >> Oh I I wanted to mention an an attack that I don't that I don't know how can it be solved. Um so the situation is goes like this. You

say that the the IL propagation time is currently at 8 seconds and the first reaction that I have is that uh you can make it very earlier because the payload we're going to force it to be available quite earlier >> right >> uh but here's the problem. Uh how do we prevent the following situation? There is one transaction that I want to censor because it's going to be rugging the full rollup. Now I see that transaction in every single I include it in my payload. I win the auction. I include it in the payload and the DA for that payload happens always at the very end of the slot. That's what we want to do if we want to actually have this propagation

of blobs. And then I I I withhold the blobs as in these attacks of like the the free option problem. So then every I the whole point of this is that the PTC deadline for DA would happen after I broadcast because we want to have this PTC as late as possible. So by the time that the PTC votes signaling that the payload is actually not available, the data is not available. the IILs are already out and the IIL's if they are built on top of the payload of the execution of the payload they will not include this transaction because they see it included in the payload.

>> Uh so so I I mean the question is will I broadcasters include this transaction or not? they cannot have the payload in their for choice yet because they haven't uh I mean some of them might have it if they see it available some of them might not so the the question is how do I proposers choose their transactions without having data availability chosen yet? Uh okay. So yeah, first thing is like at least to me uh the selection of transactions from uh includers is just based on the meool.

Uh originally like they will run you know they'll get the latest head they have and then they will just like include transactions from from the main pool >> right? So but the the problem is that now they see a payload that includes the transactions that they have in the meool. They can see the payload. They can even execute the payload but they cannot still import it because they don't know if the data is available or not. So if they do their own sampling and their own sampling tells them this payload is available >> then they will not include uh a transaction that is being actually censored because they see the payload as available. they they see the transaction being included,

>> they they will not submit that transaction in the IIL, >> but still the payload would revert because it's not available. Yeah, I see what you mean. Okay. Yeah, we need to think about this. Um, >> so I think >> I think it's fine if the committee is long enough, right? If the committee is is large enough, at least one member of the committee will not have sampled that payload, will not have been able to import it and will still include that transaction. Um and then so what's the worst case will will be that transaction is not included in

for this slot but it will be on the next slot, right? No, because uh if it's not included in this slot, then the the next payload advances the chain and then it's going to be again in the IL for the next slot and then the builder can play the game again, can can win the auction again, right? >> The next block and then the gas is not really increasing because we're having like one full block and one empty block. Mhm. >> Yeah. Uh yeah, I need to think about this more, I think. But it's uh interesting.

[Music] It would mean we would Yeah. Cuz because then you have like a bit of an issue like cuz like Okay. Like if you don't sort of like talk about attacks, then you want sort of like the IL like the includers to build their IS based on the payload they see, right? Like you sort of want this. Um >> yeah, I think that the main difference here is that the IIL it it can never really be fresh because today with Fossil like this is the biggest interaction with EPBS with Fossil as far as I can I can see which is today with Fossil when you're building your IIL you

already know the validity the full validity of the payload >> DA and and execution >> but in EPBS you're going to build your inclusion list without knowing the DA of the payload. uh and I think that's what needs to be researched and we need to have like enough includers so that if the payload even if the payload is not available then they will include uh transactions um that were included in the payload. >> And then some includers will just reinclude them.

Uh Terren, >> right? So even today like the notion of the IIL does not dependent on the concept of a parent hash right just if you look at the inclusion this there is no field that says a parent hash I can today I can import a IO into P2P and broadcast it >> without knowing the parent hash and basically all it matters is that IO can be executed at the end of the block if it's otherwise it's not satisfiable so that kind of makes it easier to reason here I guess I guess the only question is that today to build the IIL you ask the the execution client to build IIL that you need to input a parab block

hash which maybe we don't need to do that for the engine API that's probably something to think about >> yeah know that sounds good okay yeah we we can we can think about it more but maybe it could also So okay so it's completely impossible to imagine having a the PTC vote before building the IL that would be >> yeah because the the latencies that are involved are much larger right so the PTC only needs one small message to reach the proposer >> while the IIL's need like all of the freeze deadline the freeze for the

builder the bit the bid broadcasting and all of this >> yeah yeah that will move basically you you you would lose lose too much time in terms of uh uh propagation time. Um that makes sense. Okay, cool. Yeah, definitely good to to think about for sure. Uh and I I'll I'll try to come back to you to you with something. Um cool. Uh anything else we have? We don't have that much time left, but um but does anyone have any questions? We can just maybe uh focus on this. Yes, Jon.

>> Yeah, I'm not sure if I just missed this, but um my question is is the full IL enforcement by a testers done based on the IL bit list or their subjective IL view. so the two no it's it's based on their subjected IL view the the signal given by the IL bit list inclusivity check is just for the proposer the testers will just do like the full sort of like deterministic

post checks uh according to their own views, I think. >> Gotcha. Thank you. >> Yep. All right. Anything else? >> Okay. So, yeah, I mean, the second thing on the agenda agenda was to talk about Glamsterdam and have a temperature check. Uh, I don't I don't know if we need to go into much detail. I think like if you missed it like you know EPBS fossil and 6 seconds slot times are like still sort of like being considered for for for the headliner choice. Um yeah

maybe what I wanted to say is like the sort of scope and feibility aspect comes up a lot about like for example doing EPBS and forol. Um but it it comes up a lot from like people that that are not like CL devs uh to be honest. So, and I've told them that um so it would be nice uh I think if you know if you've worked on either of them or both um and you have an opinion about whether it's possible or not or how much of a delay it will be um to either voice it or I don't know just like um you can do it here you can do it to me you can

talk to Jun you can do it on ACD but like I think it would be nice to have like clear opinions from devs that are actually looking at the code and that have sort of like started implemented implementing these um this these features to to give an opinion on this um and uh yeah other than this I think it's also nice if you haven't checked the glamsterdam glamsterdam sort of like feedback thing on it magicians Um uh and yes, I agree. I asked Terren first. Uh but yeah, if you haven't checked the Glamsterdam uh what is it like feedback, uh thing for

Okay, I don't remember how it's called, but like basically there is a page. Yeah. Soliciting stakeholder feedback on Amsterdam. This is here. Um, and you have a like a bunch of people that are like cheering for for for soul um there. So that's kind of cool. Um, and it's also nice. I feel at least to me it was nice to see how also like informed like like each member of the community or was on like the the process. And I feel like it will be nice to have continued more informed takes about uh what people want to see. Um but yeah, I thought it was fun. Um and yeah,

does anyone have comments on on them generally? If not, it's perfect. Uh, in terms of time, we are at the hour and yeah, thanks a lot all of you for attending and and see you soon. Bye-bye. Thanks.