Fast Confirmation Rule (FCR) Primer

Transcript

interesting. >> So I think we can start. >> Yeah. All right. >> Cool. Um hello everyone. Welcome to the fast confirmation rule workshop. Glad to see you all. Uh so basically the goal uh of this workshop uh is the uh kind of educational one uh just to present the algorithm go into these complexities u and uh yeah gather early feedback and facilitate uh its further development and deliver to the main. So does it work?

Huh? Yeah. Clicker. All right. So, today I'll go through the algorithm overview a little bit uh the spec overview. Probably somebody already see the spec saw the spec on the um GitHub. We'll touch some some of the complexities of the um algorithm and uh potential implementation challenges. uh also cover potential improvements to the algorithm and uh yeah testing and delivery uh a little bit about API as well. So I it's this is going to be kind of like

presentation but feel free to stop me at any point in time to ask questions. Um and yeah I think we'll we'll do this uh the first part and the third part just a discussion and follow-ups I mean like we'll go through the slides the first part this um two hours and yeah then do some follow-ups. All right so the algorithm So yeah, let's start from like the uh high level from the consumer's perspective. So what we try to deliver uh what's the and uh yeah it makes sense to start from the definition of the confirmed block. Uh the confirmed block uh in the context of this algorithm is

safe and synchrony assuming no more than 25% of total stake is adversary. >> Is the is the 25% a hardcoded number of the algorithm? No is is the maximum number. So >> we are reducing the honest validator thing from 67 to 70 like right now I think 33% can be adversarial and now it's like >> yeah yeah exactly it's it yeah it can work with 33 but some of the things are uh doesn't look safe. uh we have been working on the proofs of the on the proofs of the safety of this algorithm and uh ended up that 25 would be uh the best uh like the best number for that

because for 33% you have to uh please Roberto correct me if I'm wrong but you have to do some uh probably more assumptions whatever so it's less safe and I we think that 25% is pretty much enough in terms of like u um the um the defraction like uh it's it's already big. Yeah. >> Okay. And uh is that like something that like the um that the users should be configured like if you want more security or less accurately like 0 to 25 or do we just need a single value?

>> Uh it shouldn't be a single value but I think it shouldn't be configurable by users. It's more like up to a client implementation and currently it's just a parameter in the um it's is the um parameter in the config of of the u in the main net and minimal configuration in the configuration basically. >> Okay. >> So it's it's set to 25% as as maximum value but yeah any clientation can you know tweak it. >> Yeah that's it >> like downwards >> downwards. Yes. Yes. And also you are working on proofs for proving that 25% is good enough. Uh is these proofs like some data related to those probes are in

the part of specs or not? >> Uh yeah that's a good question. I don't know. Um actually it's just like for now it's it's our understand that like it's our perception that like our uh view that 25% is not we haven't I believe we haven't checked yet. Maybe Francesca you know something more about it. Yeah I'm sure. Okay, >> with the current algorithm like if you have more than 25% adversary can more easily prevent confirmation then you don't see anything being confirmed

and now you don't know whether the whether there is a network problem, whether the vers is just not participating and preventing blocks from being confirmed. And like if you set the threshold higher actually the adversary can prevent confirmation with a lower threshold because like you expect more more attestations and so now the adversary can be even smaller than 25% and still prevent confirmation. >> Okay that's problem.

>> Yeah. Thanks a lot Roberto. Um so the synchrony assumption that we made is basically means that the votes cast by honest validators uh will reach out to all other honest validators by the end of the same slot. So that's that's for the synchronous part. Um right that's one. So the performance of the algorithm uh that we have measured on the tech proof of concept implementation this is the data from the mainet uh yeah it's pretty pretty good so in three slots you have 99.5% blocks confirmed um and uh yeah this this this delay is

in second but basically it's like 12 seconds is one slot 24 seconds is yeah two slots and yeah so of course uh the problem here uh So the problem why why do we not confirm a block uh at the beginning of the next slot all the time is basically because there are late blocks that gain um might might gain less attestations than it is required to confirm a block or uh because of empty slots seing the block. We have a we will cover empty slots uh in this uhation later on. the late blocks part as well will be covered. So yeah this is the measurement of the current of the

current repurposed subject. This this is what we we can do which is good. All right. So the illustration this is kind of like my mental model of the fast transformation rule. Yeah, there is like something stable surface uh um in terms of like a reliable which is close to the head that we provide to consumer. Um there is a gasper that does not by default provide that and there is the fast confirmation rule to fill the gaps of gasper to do to do this work. So from this illustration we can conclude that basically a confirmation rule is at top of the core protocol. It's not a part of the core

protocol. It's it works at top of it. uh and also like uh it's quite it's quite sophisticated algorithm in some sense uh to fill all the gaps of the Gasper uh of course Gasper can provide finality it's it's pretty stable it's it's also pretty stable surface but here we're speaking about something that is much more to the head than than the finalized block. All right. Uh so how do we run the algorithm? Uh at a very high level we do run it every every slot. Um uh at the beginning of every slot we attempt to confirm the most recent block uh that belongs to the canonical chain.

So what does it mean actually? Uh suppose that in slot 10 we have confirmed block B. Then in slot 10 plus one we will uh start from block B as a confirmed one. So the algorithm remembers what the most recent confirmed block is and uh attempt to move forward. Uh so we will confirm block B1. Uh for instance in SL 10 plus2 uh we failed to confirm B2 because probably this block came too late and did not attract enough uh um votes and yeah we tried to confirm B2 and we failed. And then in slot 10 + 3 if the more attestations for B2 will come uh we will um uh or more attestations will come or you

know it just will be a very good participation in in the slot of block B3 uh we will be able to confirm two blocks. So it's basically uh we start uh so the the main uh thing here uh from from this slide is basically we start at uh what we have finished with uh during the previous slot and forward as much as we can. So it's an iterative u iterative execution which is also like an upside of this of this approach this algorithm. Uh then the question where do we start? So um suppose your node just have a sort up it does not know anything uh about the

confirmed block and by default it will use the finalized block as the confirmed one. Uh and uh yeah but we need a start a safe starting point uh to start confirming blocks that are closer to the head and uh there is a category of blocks that we uh that are safe to start with. Um this is the um the basically the unrealized justified checkpoint route block. Uh and uh we actually wait for the unrealized justified checkpoint.

Yeah, we start at the epoch boundary at at the very beginning of of the epoch. We check uh if we need to start if we are kind of like uh if our confirmed block is uh uh way behind than what it could be and uh if we find like the unrealized justified checkpoint that we have observed at the beginning of the last slot of the previous epoch uh and this this unrealized justified checkpoint is is from the previous epoch. So then we we can use it as a safe starting point. Uh this is because basically the this unrealized justified point uh that we observed at the

beginning of the last slot of the previous epoch now since we turned into a new epoch become becomes realized for all honest uh assuming synchrony it it becomes realized for realized justified checkpoint uh for all honest uh nodes and for all honest validators and moreover it's the greatest justify checkpoint uh possible. because it's from the previous. >> Is this from based on the Python spec or is this based like what is the implementation that this code is referring to?

>> Uh it's it's yeah it's from the yeah it's from the spec. >> Okay. Okay. >> It's from the PR. It's just kind of like mix of pseudo code and English. So it's it's like basically >> no no I mean in Nimbus uh we um only store one checkpoint and like after we realized the checkpoint we forgot about the historical unrealized one and we just override it. So in our case this is essentially just a regular realized justify check because we realize everything that's unrealized.

Not exactly because you also need to uh you also have to check that this unrealized justify checkpoint has been observed by your has been in your local view a slot ago. >> Yeah, I I'll have to check that. >> Yeah, of course. So, it's it's a bit tricky. Um this a slot to go observation is required because we we want every honest uh node to ensure that every honest node in the network also see it.

>> Yeah. >> And which is assuming synchrony uh will be the case. Um so what should I say else about ah okay so when we start uh we find this um safe uh checkpoint to start with and also in the same um in the same run the algorithm will attempt to confirm as much as it can. So starting from this unrealized justified checkpoint moving towards the head of canonical chip. So that's basically about start point.

Yeah. And by default I I also I already said that but by default it will be a finalized uh block by as a confirmed one right. Yeah. And uh also this brief ebook unrealized justify checkpoint is the new arrival in the store. >> Yeah. Uh the chain is not finalizing it. Uh you have no starting point. the like you just the chain is really unhealthy. So start EPO boundary where this unrealized uh justified checkpoint is the previous epoch.

>> Yeah. >> You don't have enough votes then you aren't confirming is that >> right? >> So you mean that if if chain is not finalizing but you see this starting point is it safe to start from it >> and you don't see the starting point? uh if you don't see the starting point uh then yeah then the uh confirmed block basically will the finalized one. If you don't see it, >> if if you cannot confirm anything, yeah, then you just wait for the the network to get recovered. Could I add something to that? Like just as a general observation, like actually it would be very unsafe under low participation conditions to to confirm things. Not it's not like a general

rule, but like in our protocol, it happens to be the case that in under certain like low participation conditions like really any kind of weird reworks can happen. Um so it's it's it's basically impossible to have confirmation rule that works under in our protocol right uh let's move on yeah so I forgot to mention that uh the confirmation rule deals with LMD ghost and with fogg as well so deals with Casper um and yeah let's just dive deeper into the first into the LMD ghost part um then we will cover the f of g part as well.

So at the high level um if we want to confirm block b n + three for instance here um it's uh yeah what would we will have to check that uh every ancestor of this block and this block itself uh satisfies LMD go safety uh condition. So we will do do this uh check for all of that blocks. And at a high level what we are looking for uh we are looking for a as a as a confirmed um as a confirmed branch of the block tree.

We are looking for the branch of the block tree that under synchrony and uh our adversary adversarial fraction assumption uh will remain canonical starting from this time onwards. Regardless of of what uh will happen in the future of how validators will vote um what rules will will come into the future what like adversarial behavior will be or whatever because we expect that basically honest validators will keep voting on on that on that branch. So uh here this this is the simplified formula of the safety

indicator on the top uh where s of bi is basically the support of the block is the total weight of the boats that we have observed in the support of block bi. Uh and on the right is the safety indicator threshold. Uh where WI is the maximum weight of all committees that can vote in the support or again in the support of block BI or in the support of a conflicting block to conflicting with BI. The beta is basically the adversarial fraction and the PB is the proposer boost. So if we simplify uh this formula and remove the proposer

boost and suppose that we have zero adversary basically we will see this very simple version where uh where the block is considered LMD go safe uh once it uh attracts uh more than a half of the maximum maximum possible uh weight that it basically can gain In this case, in this case, uh yeah, we we can be sure that under symfony all honest validators in the future will keep holding f in the support of this block and uh this safety indicator uh inequality will hold all the time

starting from now. So the block will never leave the canonical chain and we do the and we do this check for every uh every ancestor of the block. So that's basically the LMD part >> in this diagram. This BN is last confirmed block or last justified BN. >> Oh, it's just some Yeah, it's just some confirmed block like this. This blue uh this blue this sub tree like this branch of this tree uh that's highlighted in blue is the like the one that we are looking for the one that is temporary. And for for each of these blocks we this check must uh must pass.

>> What is the like um there are if some validators are offline on top of the adversarial state like the weight only counts the actual votes right. >> Yeah. So if like if I have a slot with like low participation and the next one maybe like maybe like if the if the network changes from one slot to the next like either from high to low or from low to high, how does that interact with this formula? So if if you confirmed if you confirm something already um it will stay confirmed but uh if the network participation drops significantly and

some mess happen in the network uh this will be a this will mean that the synchronous assumption is broken. Um >> yeah. >> Yeah. And uh >> because the W just scales to a comp like because the W like the safety indicator threshold depends on the online percentage. >> Yeah. Exactly. >> Nice. >> Yeah. And and yeah if if >> W is the entire committee is independent of the participation. >> Yeah. But support is dependent of participation.

>> Yeah. The support not the W though the support is dependent the W is the is the is the weight of the committee regardless of how many are online that's not like based on the actual yes so if you look at the one the simplified one below on the right it's always going to be this fixed fixed based on what the size is just like the total amount of weight evaluation but on the left It's just the actual rules that you see.

>> I see. >> So if there's no participation, you will just knock down the application. >> Yeah. >> Oh, sorry. I I misunderstood the question. >> I thought you were asking like what will happen is basically if we don't see enough votes. >> Yeah. Yeah. No, then it makes sense. I thought like W is weight like in the for choice debug. I think weight means the actual vote and not like the weight of the >> Oh, I see what mean. Okay. Yeah, >> I'm in a different term. >> Yeah, that's the maximum weight. All right. >> Hey, thanks. Thanks.

So what we have here is we are trying to confirm block and uh we suppose that adversary is basically adversarial production is 20% for simplicity and uh every and the maximum weight of each slot committee is 100. So we are in uh in the slot after uh block B13 um and uh here to confirm B11 um we basically need to take into account the slot of block B11 and yeah the votes from the slot of block B1 and the W from the um slot of block B13

um which is like we have 80 and 85 five uh score respectively. So the total is 165 and we have a and the weight is 200 because there are two committees. Yeah. Also so we just basically pass these numbers to the formula and we get that the threshold is 160. Um which is uh yeah and the actual weight is greater than this threshold. uh which means that P11 will be confirmed. Also pay attention to that the B13 has a proposer boost value. So it's like

it's a time blocked but this value is not uh um is discounted from the formula. So we discount this weight from the B11 support. Yeah, it has 165 because uh uh the B B13 is the uh descendant of B11 and uh its weight also u adds up to the B11. So that's basically the how the computation happens. It actually the formula of the threshold is more involved. uh yeah you know but this these are the main components of this move on

all right uh yeah let's cover a bit the empty slot stuff the empty slot case uh as I mentioned before we we have to w uh so we have to basically count uh to check if the block is confirmed um if there is enough support with respect back to uh the weight of all committees uh that can uh can vote in the subord against this in the subord of uh the block in question or in the support of a block conflicting to to to that one. Uh in this case um there there is a slot K uh which has no block which is empty slot and uh in our computations we have

to take this also into account because during the slot K um there can be votes uh not in the support of block P10 which is the parent of P11 but in the support of the block conflicting this one and even even if we have a perfect participation which is illustrated here uh we will not be able to confirm this block uh immed immediately because there will be not enough uh support to outweigh this uh this maximum weight which is uh 200 in this case as well.

Yeah, because 100 from the slot will be 11 and the other 100 is from the empty slot. So we handle this situ situation this is one of the like uh complexities of the algorithm. uh we handle this situation in the following way. Uh we basically count the honest support uh of of the parent block during the slot key. So here you can see that the honest the the total support of of of the parent block during the empty slots was 100. So all voting in favor of uh to compute the honest support we need to get the support of the parent block strictly from slot K. Uh subtract the potential other style roles from that. Uh so and

yeah and uh discount this owner support on the parent law from the from the safety threshold on the right and uh yeah this basically in this case yeah the adversary is like 10% we can confirm B1 at the next slot but in the case of 25% it it will still not be possible so empty loss really uh delays the confirmation but yeah uh By doing this trick uh on this slide uh the the delay is kind of like reduced.

All right. Something something similar happens with like blocks as well. >> Late blocks. >> Yeah. >> Can this go negative like when the support is >> Oh yeah. Yeah. Of course it can. >> And when H is negative. >> Yeah. Yeah. ID >> it can go negative but uh >> it's just a current committee like with with picture we have this similar stationation right where in theory someone that's not in the committee can make a valid attestation message that still has a valid signature um we are discarding those

wait so what's the situation like with the single attestation type that we have in Pra anyone can make any attestation at any stop um they are still slashable but I think they are not countable they're not in that >> yeah um but the network type has a validator index instead of like a bit mask into >> oh you mean like with the single stationation I see >> yeah very much.

>> All right. >> So, should we move on? >> Yes. >> All right. So, this this is like the um LMD ghost. Um as I mentioned the formula is more involved. This Honest support cannot outweigh the W actually. Yeah. But anyway, so there is in the explainer document that uh Luca uh has recently shared this formula like uh outlined in all the details it has. It's it's more um yeah there are a bit more details in that. So f ofg high level. So what the um what the fast confirmation rule has to deal with f ofg is basically uh the

main point is uh we have uh suppose that we have ld confirm some block but uh uh we all yeah you're all familiar with these checks uh in the um get path filtering um and basically the algorithm ensures that uh the confirmed block the confirmed block is not is not going to get filtered out during current and next because yeah it can simply filter filters out and uh it becomes not an artful block. Yeah, that's uh that's what the FFG part of the algorithm deals with. And uh if if the block is not filtered out during current

and next epox um the next epoch checkpoint uh will be and assuming synchrony the next epoch checkpoint will be justified uh and it will this justification will be realized two epochs after. So yeah and yeah this block will have a justification justify checkpoint it which has a which is a descendant of of the confirmed block. So yeah it will then from that time it it will remain canonical uh and we will not need to care about this filtering anymore because yeah it will remain in the canonical chain from the filtering

perspective. Uh and also the algorithm does these two checks which is will checkpoint be justified for current blocks. A similar check that no conflicting checkpoint can be justified for previous blocks. Uh this is like the check to ensure that the checkpoint of the current book uh will will be justified given the synchrony assumption and given the votes that we have already observed. uh because yeah if if if this check does not would not pass then we cannot say that uh the block is safe because let's just imagine if we cannot justify the checkpoint uh uh from the

where this block is from uh then basically potentially something conflicting can be justified and uh will mean that the block yeah it just means that the block is not safe to use is not it's not burn so we do these checks kind of like cooking a into the future with the votes that we already have like supposedly in the middle of the uh we know that how much votes can be adversarial from that support and we also know uh how much source left uh to vote uh we we have this adversarial threshold and we can assume that all honest will support this checkpoint.

This is basically and if this all if the sum of all uh actual and potential support uh is higher than the u justification threshold then basically this check uh passes. So this is how it kind of works. Um yeah so filtering checks I don't want to go through this now it's just basically more for illustrations here but there is a quite sophisticated logic to ensure that uh that block is not going to get filtered out uh or previous epoch blocks when we confirm previous epoch blocks and when we confirm current blocks. So if there will be a need we will get back to these

slides. Uh yeah. All right. So failures uh the how the algorithm can failure. Uh the first one the first failure is basically uh the confirmed block appear to be not part of canonical chain anymore. So this is the safety failure. Uh it must never happen if the assumptions hold. Uh but that that could happen. In this case what we do we basically revert to a finalized block. So we we explicitly say that this block is not safe anymore as a confirmed one and we have to do revert.

The other two failures uh the second one is uh is related to reconfirmation. Um we will cover reconfirmation later. The third one is suppose that we turned into a new ebook and we see that the confirmed block is um yeah first of all there must be something bad happening in the network. So the assumption again is broken because otherwise it would it should not happen. It should never happen. Um and uh in this case uh we just stop confirming because it is uh difficult to show that the block is not

going to get the red out that it will be safe to use. So this kind of like this uh and the failure mode for all these three is basically revert to finalized block. Uh for the first one it makes uh sense to revert but for a second and third cases uh probably not. So yeah, we'll cover this later like is this could be one of the improvements of thinking about the failure mode for the third and the second uh for the third and the second case um because in this case basically the block remains canonical.

So in the third case in the third case we would have to wait until finality is restored and then the algorithm would start working. uh we will have to wait for the starting condition. So we basically use it as a restart as well. >> Yeah. But the start is from >> finalized right? >> No uh we no we will yeah revert to finalized and we will wait for this starting point again. >> Why do finalized why not justify what?

>> Uh because justified is unsafe can be unsafe. Yeah, justified by design can be >> Yeah, it can be real. Yeah. >> Um, so because like you only have like two epochs that we have to consider that also is like an upper bound for the implementation like run time that this stuff needs like because if the starting point like if the last confirmed is too long ago. >> Yeah. Um we only have to look at most at two fully box of blocks >> in the implementation.

>> Yeah. >> Yeah. >> So that's good. Yeah. >> Yeah. That kind of limitation on the complexity on the data comp. >> Yeah. That's good. So even if it's like quadratic or like whatever the algorithm is. >> Yeah. I see. Yeah. That's the positive side. Yeah. So the algorithm basically Yeah. This is the failures. Um most >> I think theoretically >> when you go >> theoretically I say theoretically perhaps we could uh in the last case perhaps we have ways to cope with the confirmed block being from two epochs ago. like it's not in the current algorithm but we thought of

possible ways like if we think that we in the last scenario we don't want to revert necessarily to the finalized block uh perhaps there is something we can do to the algorith to cope with the confirmed block being from two epoxy by by coping you mean like not to revert it but and Not probably and not confirming until the certain point, right? >> Yeah. And determining that it's still safe like >> Yeah. Yeah. Yeah.

>> Oh, yeah. Like because the third condition can like regularly, right? Like that can happen like when finality is broken. >> Oh yeah. Not on the mainet, right? >> I mean >> theoretically. Yeah. >> Yeah. Yeah, but on holis it would happen definitely. >> Yeah, holis was like uh a situation where like a justified checkpoint was like >> based on an invalid, >> right? So what Roberto is saying basically we can uh we will stop confirming. Yeah, >> we probably can find some conditions to check that this block is still safe to

to to rely on, but we just stop confirming. >> Yeah, that makes sense. Like for infrastructure providers, you don't want uh save to go back. >> Yes. Right. But uh there is a failure mode when you have to go back finalized. But it's quite like >> Yeah. Like the first Yeah. The first two, but like the third one I think. >> Yeah. The second one probably can the sec the second and the third one is more kind of livveness uh issues >> or maybe safety as well but we will try to find a way to you know >> to understand whether we can still keep them.

>> Yeah. So this is I think conservative and safe. Um the first one is is there a reason why we don't just go to the parent block or like why is everything not >> that's a good question. Yeah, it's a good point. Interesting. I don't know. >> One one thing about is that if a confirmed block was reorgions were violated so well, >> no confirmation is like known to be safe, but like >> I don't it could also just be fine. I think would be fine to just go to the the latest confirmed thing that is still canonical.

>> Yeah. All right. That's a good point. >> Yeah. Makes sense. >> Okay. I was just going to ask uh from like a user perspective from the time I'm going to confirm to a reverted finalized block like how many seconds or minutes or whatever would pass from the confirm to to to uh like how many in terms of like really physical like >> well I guess would a user like have a sense of okay this has been finalized and then moments later just the transaction would fail and it would revert or would it be minutes later would they

>> uh it depends on the network condition basically. Um so but uh we yeah that's it depends on the network pretty much. So if if we have uh uh something bad happens if if we lose finality and uh you know um some mess happens that the block is revolved. Yeah, it can can happen. It can happen like I don't know maybe in minutes or in a couple of epox. Yeah, but it's very unlikely. I mean, at least we haven't seen yet the accident on the

mainet that would lead us to rolling back to finality. We've had like nonfarity on mainet back when um started the captain without testing it on test and it released very old stuff >> right but uh I believe that the participation didn't drop enough to stop confirming maybe I'm wrong >> yeah right >> but yeah this one is now this one is 75 >> no no 75 you're right yeah >> so varity is less than >> how How many ebooks of nonfality we have had by then? Like look it up. It's like a couple years ago.

>> Yeah. Yeah. >> And >> that was a scary one like that like it was like a different layer that rocked us there. >> Yeah. Okay. So that's the algorithm. This is a p s pseudo code. Um like what's on the left is the um the get plate is confirmed here. It's basically Yeah.

Just Yeah. I see this. Yeah. This this function is the certain point. Um what's on the right is basically this function that looks for the most recent confirmed block along the canonical chain. And uh we have a safety proof for this version of algorithm or this algorithm that basically the proof of safety that what's the that the output of this algorithm that the output block is basically um safe to use uh given the assumptions um okay what's that

>> to read about like Ethereum finance ity loss. The website is called Solana floor. So, so Solana reports on Ethereum like we we are on them. They are sh that makes sense for >> 47 missing blocks. Um delays >> this boost. >> This was the 2023 one. We had like two days um four epochs and nine eps.

>> Nine ebooks. >> Yeah. Like they they turned it on and it was four epoxy. Then it like shut down everything and then they turned it on again and then it was nine. >> Okay. >> Because we didn't know what it is. >> All right. So then we would be in a situation number three. >> Yeah. >> During that likely. So, >> so I mean in that situation probably just staying >> Yeah. >> what we saved because there was no branching it was just lot of factor. >> Right. Right. Yeah. That's one of the potential should I mean >> all right so the algorithm yeah let's move to the spec.

Uh there is a PR to the spec. So it's just basically exerves from that PR. Um so what's in the PR basically one more kind of similar to the fox choice handlers one one more handler specific to the bus confirmation rule it's more or le it's kind of artificial handler but what what it's what it basically uh tries to show is that the confirmation rule should be run at the slot boundary at at the new slot at the start of new slot after attestations of the previous slot has been applied. So to take them into

account has been applied to the fork choice. So if you're say if your client runs the fork choice uh for slot n + one at 11.5 or whatever seconds into slot n basically this would be the uh moment where you can also run this uh this code or the confirmation rule. But bear in mind that uh basically the confirmation rule also uses the current slot which borrows from the store. So it should be also kind of like the the next one the next the next slot if you kind of run it before the next slot action. what it what it does it it runs the um the algorithm stores

the confirmed route and also updates a couple of variables that also uh are added to the store and used by the algorithm. So these two used by the algorithm the precon point you already saw the crystal head is basically yeah the hat of the observed at the beginning of previous slot. Um right so the get next the get latest confirmed is basically the entry point it has three blocks failure handling we covered that this is where we were finalized then the starting point we also covered that this is where we start or or do a restart whatever yeah and

then basically advance the confirmed block uh towards the hat as much as yeah this finally is confirmed descendant quite sophisticated one. These eaves are very complicated. So the blue lines uh this is basically where the algorithm deals with casper f ofg like this the blue blue line the blocks highlighted by blue vertical lines and the green lines is the lent ghost part. uh the method is called is one confirmed which basically checks the support and uh compares it to the threshold and yeah if this check pass the this block is

you'll see so basically this is a movement from the previous confirmed block towards the hat uh overall each canonical route and doing all these checks yeah to all Right. How much time please? Um let's probably like finish this great and do it greater how complex it is maybe interesting part. So now it's time to talk about reconirmation which I mentioned it a bit before.

This is Roberto please uh correct me if I'm wrong. This is more a theoretical thing than practical one but also yeah kind of theoretical challenge. So what we have to do is basically at every boundary we have to run is one confirmed like check that the blocks are still safe the blocks from the previous not like yeah so all yeah this this is quite intense check.

So we basically reconfirm. We do not do the filtering checks again but we do the uh those save checks. >> This one is not bound that >> it's bounded. >> I I mean finaliz >> it's it's only for the previous >> just for the previous >> for each confer okay yeah >> yes so this is required to reset the global stabilization time. If we don't do this operation uh the global stabilization time will have to we will have to assume it to start from the certain point which is like can be I don't know six months ago year ago whatever so you start at some point and you will have to assume that

all civilization time start there as well but by doing this exercise we are resetting it. Um this is why it's like in practice uh it's probably you know practically speaking I don't know Roberto if you want to elaborate on that. uh not probably the only thing to add is what is global stabilization time is the point from which we assume that the network is good essentially and if we don't run this check our assumption is that the network has been good since the time we started the we since the time we we hit the we hit the restart the

condition to restart the confirmation which as Mikai said could be 6 months months ago. Um yeah and I think as Mika was about to say probably in practice this is not I mean come up with counter example where if you don't do this and uh uh GST is actually uh and and basically it's GST is uh is older than than thanox sorry is more recent than Then two epox um the safe the safe block is not safe

anymore but is a counter example are very contrived. So it's probably very unlikely in practice that um if we don't run this check we have any problem. But yeah um at this point from a theoretical point of view we we need this. >> Great. Um small one no propose a boost. Um so the subport of a block the score of a block must be uh like that we check must be with the discounted proposal boost value

uh which is not the case for the full choice implementation where basically auto array uh weights come with proposal boost I believe yeah depends limitation dependence dependent but something to bear in mind so you can run uh the confirmation rule at the point where proposer boost uh is zeroed right so there is a point in time but uh yeah uh but the spec does not have it so it's a tweak that probably you have to do in in the >> yeah either we can record like the source without the proposed and like

synthetically added while not killing it because it's only on the head, right? >> Yeah. >> Yeah. So, just probably the other one, the hook fitting hook. Um, that one has to be like the outst Why is that a separate one compared to like the on like >> ah yeah yeah >> just put it in there. We can even it's not the same thing I guess because like if there is a legs pack and you'll have like an empty slot we call antations twice or like is it called once per slot?

>> Yeah once per slot and per empty slot as well should call. >> So even if you receive no at the station there is like this on slot after stations apply. >> Oh but uh you don't know if you receive no add stations right? >> Yeah yeah yeah. So, so essentially if I call this within on tick at the start before I update the time I have to say it before you updated what I update the time to the next slot uh after after moving to the next slot and after station applied from the previous slot this must run >> like start of the next slot or ear and

after last basically start of every slot. >> Yeah. Yeah. So time is already advanced right? >> Yes. >> Yes. >> And the attestations applied is referring to previous slots at station. >> Yes. Yes. Exactly. >> Um what happens if I receive an attestation after like there is like this clock link into the gossip. Uh >> you mean you receive attestation from the previous slot? Uh after that >> yes after I already called so >> it just doesn't it maybe it has an effect on the reconirmations or >> no it should not yeah you you will run this in the next slot which will take

into account that lateration >> okay so so I can call this it doesn't m like if I call this too often it's also okay >> yes it should it should be okay yeah so as long as I call it at least once per slot it's fine Yeah. And also yeah there is uh which is uh so that you record uh the unrealized justified checkpoint in the slot head at the beginning of of the slot. This is important.

>> Yeah. Yeah. >> This is because of the synchrony. If you call it too late uh say like two seconds uh before the next starts there will be not enough uh like the two seconds will be not enough to ensure that all the honest validators have seen this uh unrealized justify checkpoint for instance it matters. So these two must be uh recorded at the beginning of the slot but the algorithm can you know probably u be trigger it >> maybe after earlier slot station would be important.

>> Oh maybe yeah there is a description in the PR like this. Yeah. But all right. Yeah. I see might be the name must be might be ah why not put this to the on tick? I just don't want this to I try to to to make it as much separated from the pork choice uh because it's it's not the core protocol. It's on top. So the logic >> I see. Okay. Yeah. Yeah. But in the end it still lives in pro already. And back then we also had to change the filter rules to support it in the product. No, >> there there was one thing that we had to do.

>> No, we don't have to change filter. You don't have >> We had like in the past there were like two chains with like 140. >> It's already been done. >> It went into a past for >> but we Yeah. Yeah. We already did it foration. You prepare for it? >> I don't I don't think so. >> What What What was the change you're referring to? uh to the filtering rules. We changed the filtering rules to be weaker. >> Yes.

>> All right. But was it like because of the fast confirmations? >> That was one reason also in practice also reduce the risk of reorgs. >> Yeah. >> By by making the filter rules weaker. So there were two >> okay >> the motivation was >> oh I didn't know that >> can you add this uh into specs as well at the node sorry non propos into the specs as a node >> uh yeah there is like basically this station score function means that it's

just such a station score it's like in this back as a note Okay. Yeah. >> Just to highlight that you're like discounting the port. >> Yeah. Okay. The next complexity is that the algorithm, the current version of the algorithm uses the committee shuffling. >> That's fine. >> That's fine. Okay. Shuffling is very trivial to compute because you just pretend that the validators that have not been activated yet don't exist >> and then you can act or like on the execution payloads that right now to procedure right now and you don't have to reconstruct this in implementation.

>> Okay. So the shaft is required for the previous and the current epoch. So if you confirm a block from the previous epoch, the previous epoch shaft will be required and same for the current epoch. It it used in places like one is reduced adversarial threshold by a fraction of locating validators. But we need to know from which committees those validators are. So yeah, this is this is this can be done because we can do this because we assume that honest never actually okay.

um and uh random equivocation lag because of the u because of the misconfiguration of an honest node should not affect this much. This is more for you know for uh forocations of many letters. All right. So mass mass slashings uh the next one is uh the next place where shaft is used is to compute the support of the parent block where we try to recover the empty slot case. But there is an alternative to that. Uh so why do we need shafting here is because we need uh to we need a support of the parent block strictly from the empty slot committees.

So this this is uh the algorithm use shuffling for that but uh implementation may if if it has a slot like yeah it may use slots to basically filter out all the irrelevant votes. So you you have slot and you have a block route and so you can basically u support without sharpen alternative but for simplicity it's just use that's the justified total balance >> h >> like I remember justified total balance I have to remember >> justified like the balance distribution

even >> yeah like the total Total justified balance in the stock. Was that in the oil specs or >> Oh no no no um yeah not total justified balance. Oh okay. So we will cover balances uh in the next talk. So different states uh or to be specific different balance distributions are used by the algorithm. So the uh this preo unrealized justify checkpoint state is used for is one confirm like for the LMD ghost check and this checkpoint might be either from the previous epoch or from two epochs ago and it not necessarily matches the justified checkpoint. The justify checkpoint is the one that used by proto

array. So basically the balance distribution can be different here. uh and uh also we use current checkpoint state by these two functions will checkpoint the justified and yeah the other one which is similar which which does the same computation but treats them differently. So basically two states or three three potential states from the previous epoch from the the uh from maybe from the two epochs ago and uh yeah the current one. So three states uh that this algorithm can use uh yeah relies on.

>> So I guess some but to what extent is this bounded like what which aspects of the state? So, so Ethan is talking about for example uh the the total um so just try to say balance for for example but as a specific subset of the state in one one of these circumstance which is used. Um, and I guess my question is, is there a theoretically uh justified way to say in in all of these or is this something that might actually have to be like are there circumstances in which at least for some of these one needs an actual full state or what's >> Oh, just balance distribution not the

full state I believe like not balance distributions but also the um what weather is active. So basically validators u records what set is what you need for this computation >> but but those are accessible from even a current head I mean you can see what what is what would happen active during object state. Yeah, but uh the algorithm requires it to be like uh not from the current head perspective but from what was uh some time ago >> from the >> from from yeah from two ebooks a from an ebook ago or from two ebooks ago in most

of the cases on the main net uh this first case uh the the balance distribution that we use will from the justify checkpoint in most of the cases but sometimes it can be different like say the justify the justify checkpoint you have is is uh like I don't know from the previous epoch but you have to use the state from you know the balance distributions from the state which is two epochs old ago which is older >> but okay but this is sort of what I'm getting as this this distinction particular between the balance distribution which is one very specific part and the state in general like and that that's that's exactly the I'm

trying to get at here like is this how likely is it that a broader uh set of requirements would sort of leak into the algorithm so to say >> um how a broader set of requirements on of this state. The key point the states are expensive. states are very expensive to keep and so the the question is if sorry I'll maybe I'll be a little more pointed than than right if if that my concern is if it's written if this and as the algorithm spec currently written it is written in a way which sort of assumes access to the state even

though it uses a very specific part of the state which is significantly more cachable computable as Ethan is getting at uh as well so but because It's written sort of naively in terms of just access the state. Um is it would be it's sort of even if right now the algorithm in fact is sort of safe more or less to to not keep reconstructing old states >> relatively minor changes in the algorithm might trigger such a requirement right or because they would look almost the same because it just assumes it has a state saves stack. So my question is it how feas and and maybe the most points

versus how feasible is it to modify the phrasing of the algorithm to make it very clear what the bounds of the abstractions are what the >> so so so that it and basically an expensive modification looks expensive there's no accidents that can happen here. >> Yeah. >> Yeah. I I don't know uh maybe we just can you know outline highlight uh uh what's uh what's used there what state is used there um and the other question probably that is reasonable can we use justify checkpoint

state all the time or at least this uh is one confirmed probably we can but there can be situations where you know where we have to use like yeah well if we want the algorithm to work as it's designed as it's supposed to be and uh uh then we have to use the uh different checkpoint different to the justify checkpoint how to deal with these cases maybe the implementation can see that okay we use the justify checkpoint uh whenever it matches the one that we once because we use the balance distriution from the

justifi because we have this in a pro right but when it deviates uh from yeah when they are different we do the expensive uh computation I don't know maybe that's the way to deal with this but uh what we what the safety the proof of the safety of of the algorithm it relies on the fact that we will use like a specific checkpoint which is not necessarily just >> I I guess but what information what specific information is is is used from that is is the key for me though like like I understand it has to come from specific tech points depending on the

circumstance um but but it's an extremely different scenario to say one just needs a general purpose access to the state period done or one needs access to a balance distribution or one needs access to a shuffle or whatever. that that that is the main and and and and the what I would ideally wonder ask is if the as specified the algorithm could be more and and and prove to the extent relevant uh could be more explicit about the subsets of the historical states that it needs precisely for the purpose of saying right now if semiaccidentally or intentionally either way if right now it in fact it doesn't tend to need to

reconstruct the state even in the quote unquote expensive case because one can do clever things with this if it's what you know at a distance one away from oops not anymore now you have to go and and reconstruct the state for real like that's what I would like to >> oh I see actually yeah >> so you mean like instead of passing the exact state we should pass the uh only the fears which >> for example for example that that's yeah >> yeah but that be I would rather uh how currently it's back out uh it's uh the balance it's this state uh that we use for the balance is called balance

source the other one is called the shaft source it's basically variable names but this is how the algorithm tries to distinguish the two but uh those are uh like deep inside of those functions like they we take them from the store in the spec. Uh what could be done probably is just you pass this explicitly to the algorithm function. So we have this for you know for the source of shuffling. Uh you know that this this is this state is used for the shuffling. So you can substitute it with the sh with the cache you know.

>> Yeah that that's kind of what yeah okay yeah that's that's that's probably like let's just discuss it in the unit. Sure. All right. >> All right. Almost done. Okay. FG support of current epoch checkpoint. Uh one of the things uh so we basically need uh to compute the actual support of the current epoch checkpoint and uh what the algorithm does it uses LMD ghosts uh to to do this computation. It's not goes through all the potential blocks uh through all the through the entire block

tree scanning for how many votes uh like whether this check yeah how many uh validators voted in the support of this checkpoint. This is expensive. So we use basically the pork choice uh data to to derive this information. And there is one of the challenges here is that uh LMD goes they only have a block route but the checkpoint is the block route and epoch paired and uh in the case when uh the first slot of epoch is the empty one and the the checkpoint block is from the previous epoch. the computation needs to uh sort out uh the votes that supported

that uh block in the previous. So it basically requires the epoch of every uh vote uh requires to be there and filters out votes by by this. Uh this is not the case for the pro array as far as I'm concerned. So it's just like it had yeah it depends on implementation as well but that's might be you know something to think about. So you basically >> can you make sure that when you make the tests or if someone I I don't know who is making the test or if they already exist but can we make sure that they cover both the Python implementation and also protoarray implementations?

>> Yeah. exhaust stiffly like uh more or less I I know that's hard to measure but uh >> that's a good point. >> I can help you getting like coverage from me if if that helps you in some way but >> yeah that's interesting. Yeah, let's talk about testing maybe later. So guys, do you do you want to like Okay. So yeah and uh so the block sub tree on the positive side as it already kind of covered a bit we know that confirm block is never older than two epox at least if we have this failure mode that uh where it's older than two epox confirming uh and we know that it never reverts back except

for the revert to finalized case. So it means that basically once you confirm something you can wipe if you do some optim if there is a need for some optimization and storing some data to run this algorithm faster. Uh yeah it's it's great that it's uh pretty much bounded in terms of data complexity. So if you confirm something you can wipe out all the previous blocks data and what you keep is basically a sub tree uh you keep this information for a sub tree that is rooted to the most recent confirmed block. Is there some something that we have to persist across restart of the node or is that like >> no >> if you restart a node you are looking for the next starting point.

>> Okay. So it just starts again and finalize on a restart. >> Yeah. Yeah. Yeah. >> So maybe that revert to finalize is not even an edge case for like a node operator or an infrastructure operator because like when they restart a node it also jump. >> Yeah that's also a good point. I know how to handle this restart properly, right? Because you don't want to this to happen uh restart. >> You don't want to h you don't want it to happen. But like if if it happens on a restart, the infrastructure providers are like um expecting these kind of things and when it just happens randomly in some edge cases on addition to them.

It's not like something new that they have to >> suddenly learned. When you restart, don't you uh lo uh when you shut down, don't you save your for choice in >> and then when you start back up, you load back the what the the view of the for choice was before you shut down. >> It's lines are doing this. >> Oh, see, but I believe it's implementation dependent, right? Yeah. Look like something like kleski is a bit problematic if you persist in choice. So having a way to clean up >> blow it out. Yeah. Yeah.

>> Especially like auto base to have the fake invalid in the shop where like uh some some concurrent keep up or some database time up treated as valid block and uh if you catch like Yeah. All right. >> Earlier my understanding of the view of the chamber was that we have had we have then confirmed then justified and then finalized. >> Yeah. But ideally yes >> but with this edge case of like reverting back finalized that means that a confirmed block can also be before justified.

>> Yes. Yeah. Because justify can be unsafe especially if you are doing a revert then you see it can only happen when something bad starts to happen in the network. So justify it becomes unreliable as well likely can be unreliable >> but same applies to like confirmed block as well. Yeah, >> it can be reorg as the justified can be. >> Yeah, of course. Uh I believe confirmed can be Yeah. Yeah. See >> can confirmed be rearched without slash shifts >> like if you confirm something uh then a synchrony starts to happen right? So you confirm something right? A synchrony starts to happen and no adversary and no

adversarial behavior detected right. >> Yes. Yeah. Yeah. I I don't think it can be because >> it cannot be rearched without splash ship or because like the bent I was referring to adversarial which means epoccation right >> not equation but adversarial can move their balls from from the uh >> suddenly switching to a different parameters. >> Yeah exactly between after new starts this can happen without slashing.

>> Okay. Okay. or adversary can do some some some other stuff like sending votes splitting views short split views can only can also kind of this >> can justify be reorg but theoretically I think it can without slashing >> I mean >> like if you if you just it depends so you can if if everyone if there is two that voted for only another checkpoint, right? On the conflicting to the justifier mark, it will be all but >> yeahity penalties. I guess you can also just wait until like everyone will justify

the current one is a high >> but like this can happen for twothird of the majority without double voting without double justified can without double voting right but uh >> and without waiting for two weeks like that's >> yeah yeah but that's that's that's hard to imagine what conditions should be there to do that if if we have like to adversarial They of course it can happen like it's it's but yeah that's something one case another case is on the mix of the asymchrony and adversarial behavior like >> yeah that's interesting. started. Um so um in a way this is just a better like

the current justified that we put as safe we probably should never have done as >> it should have been finalized because we selling justified as safe right now telling people hey just use this safe thing it's an API >> it's called safe not to anyone API. Yeah, because Salana will start to complain >> but it shows up on ether standards everywhere right?

And for lava I think >> I don't think they I actually I don't know who used the same uh people exchanges mostly of them they use just like some blocks some K confirmation of >> very scary as well like I like 30 confirmation they ignoreity very >> they ignore justification either so >> yeah that's a good thing I like uh >> yeah yeah >> all right let's try to finish uh partial improvements do reconirmation in a more efficient way.

So this is as we said theoretical more theoretical thing. We don't want to affect this to affect the um algorithm realm but it requires more thinking and research better failure mode for cases when block is remains canonical. We have covered that pretty much. >> Yeah. >> And do late block handling. So for the late block handling uh here is the here are the numbers. If you use the same approach as for the empty slots handling uh we can see the improvements uh where like in in two slots we have 99.14% will confirm which is great. Yeah numbers are quite appealing but uh the problem with the late block is that we

need a proof that the same approach would work and would be safe to use as we used for the active slot. It's not yet done and uh I don't know if we yeah if it actually can be done. So there is a it's a question >> like late block meaning like some clients reorg late blocks in some situations like not in every situation >> and other clients don't like which which case is this late block? Oh, just uh 50/50 like 50% of of attestations come to the parent, 50% come to the clock that come late. You are not going to rework this one, right? Because the

threshold is pretty high, but it affects the um confirmation >> or like if it's an epoch transition. >> No. >> Yeah. If it's an epoch transition, if it's Yeah. >> Yeah. Then I think it never gets Okay. There are some cases there. >> So late blogs are much more of frequent thing than the empty slot. >> Yeah. This why it adds like you know u adds some more significant number to like in terms of improvement uh of the performance.

All right. Quality of service and API. Uh so what to say here is basically this algorithm is not on the critical path of the poor protocol. So it can it depends on on the consumers of a client. Uh basically if it runs for one second probably it is fine maybe for you know the the iteration of the algorithm if it's not super optimized. uh but uh maybe some consumers yeah it it uh uh theoretically I don't know how practical it is but uh this algorithm can be run in the same slot uh like in slot n to confirm block from the slot n

after if if after the stationation boundary like after the at the aggregation boundary um because if especially if it's a super node and it subscribe to all the station subnets. It can observe enough already to confirm a block like not wait for the start of the next log but it can uh confirm it pretty fast like in maybe two seconds or 4 seconds after the block was published. Uh in this case it it definitely will have to be fast. So yeah, so the quality of service depends >> just I guess brief maybe pedantic point I don't know about this the super node as specified has nothing to do with

attestations wait sorry the super node as specified has nothing to do with >> oh no I'm not like yeah it's okay if a node is subscribed to all theations >> yeah yeah that's that's all >> yeah okay that's right >> uh for the nodes running validators this algorithm can be disabled like they don't need it, you know. So, yeah, probably probably not. So, if it's not fast enough like it's if if if it's incur some additional uh load uh yeah zero, we're going to reuse the save block. Um bear this in mind. This is already in the spec and potentially if it makes sense uh we can incorporate confirmed

block into beacon API similar to the finalizing execution optimistic flags. So this is confirmed. Um and yeah >> how of like um because this is running on top of the protocol and I also saw in like the previous talk I think from defcon two years ago. >> Um I think they ran some tests with a partner where they like uh ran it through the debug for choice endpoint. M >> so it reads in all the information is already there.

>> Yeah. Um, so it we also probably don't need additional states or I mean if they already read it with the existing APIs. Um, but um >> I'm not sure if this version can be but >> yeah like uh um but like uh I was under the impression that there were situations where it was possible that you get the confirmation even faster than 12. >> Yeah. Yeah. Yeah. Exactly. I guess it depends how frequently you called it >> uh on after attestation processing.

>> Um if that's the case um we also need an API that you can use to like get notified when when the same thing changes because it's like outside of the beacon block. So either like an event endpoint similar to the existing preor one um or I think there is also an event for >> okay >> I don't know yeah I see but uh yeah this is something to think about >> that's missing from >> huh >> that's missing from this list uh so that's why I mentioned it >> oh you mean like on the event stream is missing or

>> yeah yeah like an event stream first case it's more of the >> Yeah. Yeah. Okay. Okay. And yeah, if we do something with the beginning API probably we can also expose some uh information if the confirmed block is stale, right? So it's like I don't know. >> Yeah. And and also like the block production process all the data port should updated >> with like payload attributes. Um should the same block dash in the call be using this or should we like like should we do it onestation uh on on after?

>> Oh you mean like on after update? >> Yeah. Should we do one after update before >> from trying to build a payload or like what will happen like >> so if you run it at the beginning of the slot right you will receive a block you will update the fork choice and send this information to to the um >> option I don't receive a block I build a block >> I all right but you will receive it pre the previous block oh you you will run it yes I see >> I have to tell the e in the previous blog. Hey, I'm going to build a blog.

Please start building. >> Yeah. >> And then at the start of the next block >> um probably I do the on after attitation thing and then another FU maybe and then I do get payload and then view payload and view or or >> I don't know. I would not uh Yeah, I see what I mean. But >> yeah, like the the glo production flow is a bit out there. Yeah, but >> right I think it's implementation dependent and >> it's e like it's spec depend because the eels are very strict about the order >> right but this spec does not say when you should uh pass this information >> what is what is the confirmation will

have to do with it's saying that fork choice updated which is the call to trigger >> yeah it's basically the API theme Yeah, >> not for >> notify port. Yeah, the pork choice updated call. It has the safe block hash. Now, this is how it passed to the EL and in the case of block production, you will not uh uh you will not do the furious update before you start producing a block, right? >> Yeah. I mean, that's what starts using. >> Yeah, >> we are sending just blockage right now.

No, no. Finalize safe and head safe is >> probably doesn't matter what the hash the E doesn't do anything. >> Yeah. >> Uh actually, yes, but I don't know how the safe block is used on the >> Yeah, >> this is what probably exchanges will switch to, right? If they want. >> All right. So >> yeah this is the last one testing and delivery we have two two proof of concepts in tech and lighthouse prism has an implementation of an old version of the algorithm so on the testing thing yeah there there was some work uh and uh this tech lighthouse implementation are

proof of concept use the most recent version of the algorithm. So the testing is just basically expo uh a straightforward and uh trivial thing to do like trivial in terms of like the test format is basically extend the pchoice test format with this confirmed root property so everyone can check it right like and uh as you said we can run this on a node and get the proarray coverage uh we can potentially use model based test generation approach but we haven't think about it yet. uh this is like to generate a lot of tests to cover all these peculiarities and all this like um execution path of the algorithm. Yeah.

No hard work required obviously because it's not on the critical path of uh um of the core protocol. Uh yeah and uh that's basically it. uh want this. Yeah, that'd be great to have it. Uh >> thanks a lot for the slides. >> Yeah, >> I I hope it was not too boring. >> No, it's very like I wonder why didn't we do this two years ago? >> Like what was like is there any reason what was holding it back?

>> Um I don't know. Roberto, maybe a question to you. Why didn't we do it two years ago? >> I don't know. Nobody seemed interested. So, we we do spend a bit of time on on the security proofs. But yeah, >> yeah, we were waiting for proof for a while. And then also the PR just never got merged like the consensus based PR. >> Yeah. >> And the new PR is red, I think. Like this doesn't pass test. >> Yeah. It's You mean Yeah. It's red because not because it doesn't pass something because the uh the flow is broken. Oh, >> because it should not check out the

repository. Yeah, that's the Yeah. >> Okay. So, so if it's ready, I can do it in Nimbus. And uh >> do we have timeline for spec test? >> Huh? >> Any timeline for spec test? >> Oh, yeah. I forgot to mention uh we have one test as a proof of concept for testing, a test generator that Yeah, we we need to we will focus on the testing in December like will be the main focus. >> So I I guess one point I would make this I I agree that the core of this is not hard for dependent which which is good.

um and and even in principle things like the engine API modifications that are being discussed or beacon API so of course don't in principle require hard for practically they've been synchronized to hard for works typically when when feasible um I don't know whether that makes sense is it worth trying to kind of I mean obviously there's a lot of approaches here one is just kind of um get this implemented get the per se the core so to speak of this implemented and and address his next hard fork. other parts obviously there's already president um that her wool and in a different context I know but but is already looking at sort of this mid hard fork kind of update for his own purposes and that could be so there's a lot of

options obviously but >> maybe it can be tied to the >> I don't know I don't want to say that actually tied to any hard it so my my personal preference would be to start working on this as soon as is possible and just you know deliver as it as we have it and We can pro probably when we see the pre preliminary delivery date we can probably think about like doing it as with a hard work or as a separate thing because uh in this case there is no change to the API at all uh except for the case where we would like to change the beacon API. I don't know what's the uh flow for changing the beacon API. Should it be tied to the hard work but I believe not.

>> No, you can just do normal final release. Yeah, you just need to build. >> Yeah, this one is probably like because it doesn't break everything that's existing. >> Um, but maybe like the new response field if it's like something like execution optimistic that's a field in the response JSON. Maybe there is some parsing if it's too strict and doesn't like extra fields that can break. Mhm. >> But like in the request like if you just add a new like right now you can say like had or finalized or justified. I think just adding um safe there is probably all right. Um, but uh it's very hard for clients to discover what

features are actually supported by a beacon API server because they botched the versioning and it's like on a per request basis rather than using this uh save block hash to notify the EL and if some EL is working with say one CL client and then they switch to another CL client and that CL client doesn't >> does not have implemented this yet. >> You cannot switch like yes or t cannot drive any from all >> like if like we had setups where this happened and the guys all those

>> issues like issues. >> Yeah. I mean we there were that issues GitHub issues. >> Sure. >> And we had I I think we had this post where driving the same year with multiple CS to save resources. >> Yes. But my point is that it's not a real thing that that >> No, that was just a question. What happens when you switch from one CL to another one? >> Oh yeah. I I the other thing I do want to say is this like as far as to follow up I guess on Ethan's point about the um attribute payload attribute version of FCU one point like the some of these are and they're not intrinsically tied to I

mean you can put them wherever in the swap makes sense whe because you were talking about in terms of the synchrony assumptions that well there should be it's actually important to not do it too late or too fine um that breaks a little bit I mean or it has be let's say carefully engineered a little bit if if one to the extent it starts um interacting with these payload attribute FCUs because in particular there are cases and I okay n could be a little a little more aggressive about always always um making sure it it you know can do it at the end near the end of a slot or but but the there's um there are cases where you might want to wait until

late a slot wait into a slot or reorgs happen or and and um so it it can't necessarily respect this I mean this specifically that part a synch the the payload attribute FCU it's like let's say tricky to make that respect the synchrony part of what you described before um I mean it can cache the values I guess but >> yeah I see so the synchrony part uh relates to those two variables >> so you have to update them at the beginning of each slot Um and the other part when you call the algorithm it basically not that tied to the slope boundary

and probably it makes sense to have a note about it in the spec or spec it in a way that it will be clear that what's what has to be done at the at this what can be done at any point in this. >> Mhm. >> So then you can basically help out breaking. >> Yeah, I think that's a reasonable I mean about this for sure. I mean I agree but also more more broadly because I think your presentation u covered several of these cases actually where there's semi semi-implicit assumptions maybe in the specs. Sometimes it's documented and sometimes the paper the spec does in

fact just say you have to this at this time but sometimes there's um it's it's inferred um from from how the and and it's probably useful to surface those assumptions. >> Yes. Yes. Yeah. Let's just uh figure this out. >> Should it be in the PR >> like this real safe block um given that safe currently isn't safe. Then should we like consider a new like maybe confirm? >> Yeah, we were considering this but that's uh >> too much effort.

>> Too much effort uh for almost no gain. >> Is anyone using the currency? the current safe uh we were trying to reach out maybe uh you guys know more uh but we were trying to reach out as far as I'm concerned we were trying to reach out to different consumers and uh um I already heard from arbitrum they use safe because they know that it's the justified block so they use actually the justified but they call it uh they they they obtain it by the safe tag >> so >> so if they assume it's Right.

But uh they actually happy to switch to finalized once we have this. >> Okay. >> I believe they will use Prism anyway and they will be aware of this uh change. So and this is the only case uh we've heard back from. >> Yeah. Then we can reuse. >> Yeah. I I I think it makes sense to reuse. >> Why? Wait, why are they using just charge if they're happy to that's actually I was I was expecting to hear the other way around is like they'll be happy to switch to um sort of safe if one but if they're happy to switch to the slower more conservative version why not they not doing that now like what like I don't understand I don't know I don't honestly

>> okay >> maybe sell your art to All right. Okay, guys. Actually, we are almost at the time, right? >> Yeah. >> I think I should stop sharing. I don't know if anyone has a room. So I think you um Roberto do you want to add any or on any um aspect?

>> Uh no I think you covered everything. Is it still working on this as well or is it only Roberto and Francis? >> Uh has like moved on to different things? Uh but you know I would say Roberto Mik and Lukard sorry I >> yeah and uh forgot to say that maybe it said but there is an shorter explainer with the intuition. Uh it's very good. So just read it. It's a very good uh uh like yeah it goes into more details uh than

the the presentation. >> Thank you so much for >> Thank you guys. Uh any questions any follow-ups or should we just uh um regroup later on the GitHub elate on that? Yeah, I mean the spec tests maybe ports should review as well a little bit, >> right? Uh yeah, I was wondering kind of like uh the EPBS case, how does it like combine with the confirmation rule? But but basically uh it should not uh be that difficult because the confirmation rule uh it reasons about the beacon blocks, right? So it's uh basically

uh if if the beacon block is confirmed then the payload that uh is the uh ancestor of that beacon block is going to be like yeah I think >> yeah I mean I guess it changes it makes things worse in that now you will not immediately if you get like a one block confirmation it's not going to the payload you're going to have to wait for >> yeah that's the same with actually >> yeah Francesca can you see any problem with the fork choice like the fort choice changes and we need to to do it. >> Okay, that's great.

>> Absolutely. >> Okay, because like the for really still runs on the regular registations and it's only like the decision at the tip around the payload that like about the last payload that might depend on the PC PTC. But this is says this confirmation rule doesn't say anything. It's not going to say anything about the things that don't have actual votes. So the last payload. So I mean as long as you interpret a confirmation for beacon block B to not mean that the payload is also confirmed then it's fine like how you consume this like you shouldn't you shouldn't take like B to be confirmed to mean that the payload associated to B is confirmed you should take to mean like what you said

that the payload uh the ancestors payload is >> like the latest payload in the state. >> Yeah. Yeah. Yeah. So like if you interpret this way I think everything is fine. It's just like a yeah the UX gets like the latency gets worse. >> Yeah. At least on the spec level I understand that but probably there can be some implementation detail. It depends on how uh implementations will handle this uh changes in the choice. I don't know. Yeah. But this something just to keep in mind. >> Yeah. Just double check. Um and um I guess you need probably December to make tests nice and everything like that.

>> Uh yeah, but uh yeah, let's start try to Yeah, let's just start to the discussion now like uh on the on the PR uh and yeah, it makes sense to start uh like doing some work al also because uh we we uh this this version of the algorithm is the one that we stick with. Mhm. >> Any improvements further? Uh it we are not sure about the timeline when they come. So it makes sense to start working on it because this is a kind of stable target, stable version. Uh so yeah and testing it just will yeah we'll work on this. I I guess I have a broader question about um the scope because

you're referring to the so this is the initial version and obviously there can be improvements and there were several points in your presentation where you noted there were kind of conservative assumption that revert to finality could go etc. So in terms of in particular obviously improvements to the algorithm are always welcome but the point of also in incorporating things into the into the API. So I guess what I'm wondering about is as Ethan was getting at about like does one add a field do you use save do you use like another angle there is exactly if if the other aspects of the definition change if if we change the way that it the revert finality works or doesn't does that does that

mean that the how the API issues I guess it's more than the algorithmic issues but to the extent that it starts being exposed to users already and fundamental behaviors change um because of improvements. >> Yeah, I see. But uh um there only one thing is that we will have a new a more uh like a better failure mode, right? >> This can change, but I think it's a strict improvement.

>> It's just better than >> Yeah. Oh, no. I mean, I agree it's better that >> Yeah. But uh we we do not expect the changes which could make it worse like you know that's uh >> okay so so so >> so it should be forward compatible kind of thing >> right so so so it would be reasonable to take even if we do add sort of API field values any along those lines to to continue to reuse those in improved ways because improvements >> yeah okay >> all Right.

>> Yeah. >> Thanks everyone. Thank you for we didn't do a break but hope it's fine. All right. >> Thank you. Thank you for presentation. >> All right. Bye Roberto. Bye. Bye.