Fast Confirmation Rule Breakout #3

Transcript

Um, let's jump in. So, Nazar, maybe we'll put you on the spot for client updates. Um, I don't know that unless Macy if you're able to speak to Teu. Um, yeah, we might just uh be limited on on client feedback today. I don't have anything anything from deco side this time.

>> Nazar, did you have any uh updates? >> Yeah, I from the Lordar side, I started working on the implementation. I shared my earlier draft PR in our last breakout call. So last week I was working on implementing the spec test and found one edge case which was not aligned properly for summer testation. So I guess Mikail has fixed this test and I run them in the morning and they're all passing on my implementation now.

So my next step is that I'm going to fine-tune some of the implementation, add some logging and then I will deploy it to some of our staging environments where we can collect some more stats on performance or other things. That's all from me. >> Uh that's great. Thank you. Um, any other client updates?

And Kyle, um, I know that you had some updates, uh, changes to the spec or proposed changes to the spec that you wanted to go through. Would now be a good time to do that? >> Sure. >> Yeah. Um first of all thanks um everyone for the feedback to this pack. Got a lot of uh conversation on GitHub. It's great. Um um yeah. So and uh there are three uh things I would like to um kind of go over today.

Let's just three changes to the spec. Let's just go um with them one by one. So this is the first one I I I opened up PRs to um to the uh to actually the branch from which the PR to the main spec is opened uh just to like track these changes and uh have a have a venue for discussion around each of them. Uh so this first one is actually the fix uh of one of uh of by one uh errors in the spec. So the problem is that uh in the existing spec uh we update the we

update the variables at every slot start and at the last slot of an epoch we update our uh current epoch observed justify checkpoint. So that we will uh that we use for for the to confirm a block. And the problem is here is that at the start of a slot we updated this checkpoint and then in in this same slot when we call the confirmation rule we use this checkpoint this updated one uh while we must use uh in this case we must use the previous one. So basically this is the problem and uh the fix is simply to add a new variable to the store to keep the

greatest unrealized at the start of the um the last slot of the previous epoch. And this uh this is what uh this variable is used for and then do the actual switch of this current epoch observed justify checkpoint and the previous epoch observer justify checkpoint at the start of uh of funo of the current epoch. So that's basically it. uh what we need to do for this is to update tests because tests are designed in a way that uh we have we also have variable tests we will probably this change affects some other tests as well. So they are designed in in in a way that this current ebook obser point is updated at

the last slot of the previous ebook not at the first slot of the current one. So that's simply the fix. We plan to update tests uh soon likely this week. I think this this one is kind of like uh doesn't need more much to discuss. just be aware of that this fix is coming to to the spec or if if anyone has a more elegant uh way of fixing this. Um please suggest only GitHub like more elegant without introducing like yet another arrival to the store.

Right. Uh moving to the next one. The next one is uh uh this proposal is from the conversation with Eton on GitHub. Um it's uh actually like a um it outlines the way uh yeah so the main the main point uh the main point uh regarding this is basically when uh this PR is about is when we call the fast confirmation rule. Um it was in original uh in original design we call it uh every start of a slot when the attestations from the previous slot are

applied. Uh but then in the uh Ethan made a point that um client implementations do not run the fork choice function before the actually before the block in the current slot arrives or before the other station deadline if the block does not arrive in time. And uh since the fast confirmation rule has has the head as one of the inputs to the algorithm run uh it makes if we run the fast confirmation rule at the start of an of a slot the implementation will have to to do a redundant call to the fork choice and call the fork choice function and then do it once again when

the block arrives. uh so and uh Eden was just basically proposing or asking whether we could uh call the algorithm after you know after the block in the current slot arrives or the estation deadline. uh we had a quick conversation um from the research in point of view and it seems like it's it's fine to do and also it's it it fixes one of the potential problems like one of the edge cases where the greatest and realized checkpoint uh can be updated at the last slot of the neighbor. Um so if we if we run the algorithm and we update variables uh past confirmation variables

after the block arrives in the last slot, it could potentially be better because we in in a very edge in in in some edge case where uh this last block updates the greatest and realized justify checkpoint. we will use a more fresh checkpoint which is a bit better considering that a bit because this is like a rare um should be rare event but the main point is like um to not do a redundant call to the pork choice. I know how uh people feel about it here like u Nazar maybe you have an opinion on that as well like whether it makes sense to you from from from the low star point to to do these to move this uh

FCR trigger to the addestation deadline. What do you think? uh I think contextually we are al we already like applying uh running the this trigger after the test station is applied so if it is just a change of the convention naming convention I think that's also fine no issue at all >> no it's it's like it's like uh the proposal is to call it after the block in the current slot has arrived and applied to the fork choice Yeah, I think this will uh be fine from our side. We can do that.

>> But but uh from your side, from your perspective, uh calling this fast content rule uh at the beginning of the slot is fine as well or not or it requires like additional call to the fork choice. I think it does require additional call to the four choice but as of my current understanding that's that is not so much performance impact if we have to do it.

So if if it's the same as the start of the slot then no problem. uh today I'm going to like deploy this thing to our our server to get some metrics out of it uh from the performance point of view then I can clearly tell you how much impact it has on the for choice >> okay um cool that'd be great >> but if we change it to then that's also fine for implementation >> got it cool um so for For this one, it would be great to get more developers feedback because one of the main points is to address this u redundant fk choice

call. One of the main points of this proposal. We will also think on whether it's it doesn't seem to break anything as I said before. But yeah, we'll also double check that. All right. We could also leave this >> we could also leave this open to the implementations right on when they wish to call it. That's also a possibility. >> Yes. >> Not to not to have specify when but yeah that's that's possible.

Um yeah, maybe that'd be the best, you know, the best thing to do. Uh one one related stuff uh one related stuff to this is that we will probably need to um kind of change the test format a bit to we have removed an explicit fast confirmation trigger from the tests because uh we decided on the previous call that um using on tick as a fast confirmation triggering tests is is is a good thing to do to go with uh but uh for for this probably if if

this change it makes sense. Yeah, but I don't know. Uh that's debatable. I mean this one of the it's just testing not an implementation actually. Okay, we'll see. Um yeah well I mainly uh uh we have been discussing this back with Ethan and Nazar um a bit and Terren as well uh left some comments on it but a lot of yeah a lot of uh feedback is coming from from Nimbus team.

All right. So let's move on to the last to the last point. Uh for this is basically um this like should be easy thing to do. Um we have this will checkpoint be justified uh call which uses the which actually assesses whether the current deep checkpoint will be justified or not. And uh for for this call we uh the current spec uses the um actually the checkpoint state to to get balances out of it. But uh there was a proposal to use a head state instead of like instead of like uh the checkpoint state because head state

is always around and head state is closer to what will be used to assess to actually process justification by the end of the ebook. Um uh it will be closer in terms of like if yeah it's fine it will be closer in terms of like if there are proposers slashing happens they will be not taken into account but it's not super kind of like impactful thing here because our assessment is still is still kind of like an evaluation and estimation of of whether is this this checkpoint will be justified or not. But using head state is fine and uh yeah if head state is

always around in client implementations then probably it makes sense to switch to the head. So more clients uh inputs are be useful here right >> is this for the FFT check? Yes, exactly. This is for the FFG check only. Okay, these are three things that

one of them is the fix is definitely coming to to this spec, but the other two are available and yeah, we'll wait for more feedback. >> Great. Thanks very much, Muel. Um Julian uh you had also noted on the agenda some uh user feedback comments that you wanted to highlight.

>> Um yeah. Um so based on conversations that will and I had with some exchanges um they seem to call um or they seem to get their information on which block is uh confirmed via their execution layer client and via engine API and I was wondering um if um if um if CL's support whether that automatically means that the engine API is updated with them as well or whether um the users would need to like do something more fancy and get information directly from the ACL.

Do we know how what EI code they use to check for confirmation? >> Um, I'm not No, I guess we're not sure there. Um, Yeah, >> I I think what happens is when you request um uh information from your EL uh you specify whether you want latest block um confirm block. I I'm not up to date with the terminology on it, but as part of your request, you specify which one you want um when you call the uh JSON RPC.

Yeah, that's yeah. Yeah. Yeah, there is safe block. So I wonder is that the way they do it? >> Yeah, I I I think so. And um Mika also uh in in text mentioned that uh since FCR will be replacing uh the the safe um tag that it will probably be automatically updated. Um is that correct me? >> Right. So uh we have this uh safe block tag which is already in place in EL clients. So you can request a safe block uh block uh why JSP API today. And now this safe block is populated with the

most recent justified block. After the past confirmation rule is implemented, it will be populated with the most recent confirmed block. uh and this is like the initial way of uh like the default way of how uh how consumers can request uh the confirm block. It does not have any additional messages on one why block is stale or whether uh like yeah what what is happening uh in that uh regard is just a block the most recent one and if in the failure case in the where in the exceptional case where the confirmed block is uh starts to is

reverted to finalized block and starts to rely on finality uh it will just the the finalized route without any additional uh information um on that this thing has happened. Um so that's that's the default and uh we are still uh we haven't yet discussed much about pick an API changes but there are some ideas how to do it and probably there we could expose more information than on the JSON or PC API. >> Thanks. Yeah, those were the two questions I had.

Great. Thanks, Julie. Um, yeah, Muel, did you want to circle back to the engine API comment? >> Right. Uh, thanks, Will. So if we move the algorithm trigger at some point into a slot uh in order for this save block that I have recently mentioned to be populated with the most recent fast confirmation fast confirm block um the like an implementation should be aware of where when it is it's call it's calling for choice updated method um in the engine API.

uh this is where basically the safe block is passed to is propagated to the E. So this is one of the things that is related to um to to the decision of uh like moving the pass confirmation rule to some other point in a slot. If if it's called in in in in the at the start of a slot obviously um uh the first uh obviously what what is confirmed at the beginning of a slot will be soon propagated to the EL by default because um CL will call for choice updated after a block has arrived in this slot or at the station deadline. But if we play with this

um FCR trigger time then yeah it may affect this propagation. So beware be aware of it. What is for choice update update code? >> It is called uh I don't know. Yeah, I'll let CL dev speak up.

I don't get the question. Uh the question is at which point the CL executes the API call to the EL the API uh for choice of the code to the year. Oh, as of my understanding is the I guess uh between the middle of the slot but this thing is going to change I believe with the EPVS implementation the four choice is going to be

refactored a lot with this EPVS implementation. Yeah question. >> Yeah, I mean as long as we execute the confirmation rule before the time that protocate is called we we are fine in terms of conf in terms of uh responsiveness of the confirmation rule. >> Yeah. Yeah. I think we're fine.

Great. Were there any testing or research related updates that anyone wanted to cover? Um, yes. So we have adjusted the test format um as per the feedback and that we have received on the last call that we discussed of the last call. Uh we also merged a bunch of tests in the um in the branch of the PR.

Those one that Luka was working on and uh yeah that's that's pretty much it. Luka, do you want to add anything? >> Yes, thank you. Uh yes, the goal now for the next two days is to adjust the tests based on the first PR that Mikuel presented and potentially add other few tests like to test like the new new new the new parts of the code and paperwise there are no particular updates. We are basically roughing up the last few things and we are we should be there I suspect mid-March with with

the paper but that's it. >> Excellent. Um, were there any other open discussion topics that anyone would like to table? I just have one side question related to the FCR. Uh, the FCR implementation is making a lot of changes related to the f

choice and in parallel uh the EPBS implementation is also changing the for choice. how other clients are uh working along with the like keeping alive some both of the development together and what's the plan for other clients to first get the past confirmation merged first or EPBS going to be the first Uh but as far as I'm aware the first

confirmation is is not changing the for choice like we are adding some fields to the store but >> yep >> we are not really changing how the for choice is executed. Yep, we are not changing the folk choice behavior but um changing the store and adding more fields. So I I was discussing this among my team about how should we proceed and we decided that okay let's uh isolate the changes for the fast confirmation so it does not get too many merge conflicts into the APBS implementation. So we will going to be merge the EPBS first and then we will uh merge the fast information with some

feature flag later on. That's what we plan in the load star. I just want to get feedback from the other clients how they are planning for it. Um I have a related question to that. >> Yeah. When do you think you will be ready to merge the PDS part? >> So there are quite a few like PRs that uh a lot of my team members are working on.

So we were thinking to go with the earlier changes that are like the changes which are going to be the work choice changes with related to the EPBS first maybe in couple of weeks not more because those PRs are in currently like in a detailed review from other team members uh including myself. So after the review we going to do some stage deployment to get some metrics and then we will merge >> Got it. So it doesn't sound like uh somewhere far in the future. No, no, no.

It's it's like the the whole EPBS will take more time but uh we decided okay some changes related to the fork choice if we can we will get them merged first and then uh we continue with the other features. We we are trying our best that uh we should not keep longunning feature branches. Uh in our experience uh from past uh that was not a good practice to keep. So we are trying to get everything to the unstable as early as possible and then uh move on the development on the unstable.

Got it. Makes sense. >> Um I have a kind of question kind of temperature check question. uh after you you have already implemented the um the whole logic um the question is basically if just imagine it's possible to use um the weights and run get attestation score or over your fork choice over the fork the checkpoint that the fork choice uses.

Uh considering that we also like count inequations and uh uh fast in fast confirmation rule and fast confirmation rule relies on shuffling. would using um weights of uh would using like these uh fork choice as a source of the balance supporting blocks simplify the implementation and how much it would simplify it. Considering my implementation uh I I feel it will simplify a lot. uh currently I am not getting the effective balance

calculations from the four choice. I am getting the state and then uh computing everything on the state. >> Yeah. So, so if we if we simplify this part and we reuse uh like the balance information effective balance information from the four choice uh then the calculation will be a lot simpler. >> Got it. Thank you. agreed.

Any other topics from my side? All right, thanks for your time and I'll post a summary of this and a link to the recording uh shortly. And yeah, we'll just continue to try to get the other client teams up to speed async. Uh I know that there are some people traveling for East Denver this week and um yeah, so we just keep at this uh every other week. Uh I think

we'll we'll start to get uh more uh attendance from a wider range of clients here soon. >> Thank you all. >> Thanks everyone. >> Thank you.