Fast Confirmation Rule Breakout #2

Transcript

All right. Um, should we get started? Not many people here but who did not attend. They they can watch the recording. >> Sure. >> Yeah. Hello everyone. Welcome to the bus confirmation rule breakout number two. I dropped the issue to the chat. So we have a pretty short agenda for today. Uh we'll start from with the client updates then u go through the testing update. Uh there is there was supposed to be a big API discussion but yeah we decided not many clients client apps are here but yeah we can probably

just cover main points here. Um okay so let's go ahead and get started with the client updates. Um close star. >> Yeah, good. So yesterday I opened the first very early uh draft of the implementation for the first confirmation rule. The PR number is 837. Uh it's in the draft mode. Now I'm trying to fine-tune the logics go through and try to match the specs completely and also looking forward to the way how can

I test the specs which were created with the specs PR. So hopefully when I start working on the specs implementation then I will find some bugs or some fine edges where need to be improvement. So but we'll keep going. Thank you. >> Sorry Nazaren or is it on my side only? >> Okay. Can you hear me now?

Yes. >> Okay. Did did you did I was completely unaudible or did I cut off on something? >> No, it was kind of fine uh for the most of the part but the end was yeah I didn't get >> so in in the end I was saying that I'm now uh trying to figure out the ways how to implement the spec test so that I can compare the implementation with the specs. So if someone already have done it or or has some suggestions to do it uh because the specs are not yet tagged for it. So I I never tried to do this uh like how can I get the spec test and from this open PR

so that I can match to my implementation. That's an open question which I'm currently looking into. Apart from that uh I guess the draft PR has good enough shape to work further uh next week. >> Awesome. Yeah, great update. Uh mind sharing the PR? >> Uh yeah, I will share it in the telegram group then. >> Great. I can uh very quickly answer one of your questions there. Like we can kick off an uh the nightly test action with uh Muel's PR and then uh that would generate all the reference tests and you

could use that. >> Yeah, it will work out. >> Yeah, great. Uh an alternative would be just uh to generate um test vectors from the tests we have we already have um and uh just provide them somehow. >> Okay. >> Like yeah it's it's going to be like a very specific just the fast confirmation test thing. I don't know. >> Yeah, if it doesn't like I I was thinking to uh generate those uh test specs locally from your PR. Uh but yeah, if if you can generate and provide somewhere or we can have some nightly

job that can generate it, that will be perfect. >> I actually think Macau's right. It would be a lot easier and faster just to generate the small subset of tests locally. I can help you with that offline if you want. should be pretty simple. >> Okay, good. Thank you. >> Yeah, awesome. Awesome. Uh that's great. And regarding the test testing update, we'll give it a bit uh later. And there is al also uh kind of maybe several open questions regarding the testing format.

Uh let's just cover it during the testing update. So uh yeah the iton rised one of the potential problem with the format that we plan to have. So yeah but it's going to be easy to to adjust the format for the client needs and generate a proper test vectors so the client will be able to consume it easy. All right. Um then any other clients here? Any other client developers here from any other clients?

And we'll start. Okay. So I IN said basically that uh he started to work on the implementation but couldn't uh spend much time on it yet. uh he he didn't attend this call because he has a conflict with his schedule and he provided a uh provided some feedback to the spec and specifically to the test vectors that we have which is good. Um I can speak on tech is still in the proof of concept state. Uh so yeah there's not much on the production development front

yet but uh hopefully we'll we'll see some efforts uh during the next couple of weeks. Um that's probably all from the client for the client updates part and I think we can move on to the testing. Um, Luca, do you want to give an update from your side? >> Yes, sure. Hi everyone. Uh, this past week I worked on several tests mainly related to conditions that we have or resetting to finalization or restarting the to the

greatest unrealized. The main goal was to to show to see whether all the conditions that we actually have in the specs and in the paper are actually strictly needed or if we could if they could be implied maybe by other conditions that we had. And it turns out that turns out that at least up until now all the conditions that we had especially for resetting to the finalization needed strictly needed. we were able to find some specific T vectors that really required each of those conditions. So we keep working on that.

Now I'm mostly focus on the restart part. So far so good like all the tests that we have been carrying they are actually that's it. Awesome. Great. Uh thank you so much. Um I've shared the kind of like internal test plan. Um it's it's not it's not uh fully complete yet. We'll add more stuff there. But uh from what we have uh planned so far uh if you can see there are many check boxes uh that are already checked. So we have a kind of pretty decent uh progress on the testing front

and I believe that in the next during the next couple of weeks uh we'll have almost all major uh cases covered by the tests like the cases uh for the fast confirmation rule. Uh so it's going to be pretty uh good coverage midFebruary. So um client implementers will be able to test their implementations against the spec. Um I've been focused on the on checking all the conditions uh on writing tests for all the conditions that we uh need to satisfy when we confirm a block from the current epoch.

Um there are kind of like about 20 tests uh written for this particular uh subset of test cases. So yeah, we'll focus on the previous epoch uh blog confirmation during the next couple of weeks. So we'll have a kind of almost full coverage for the find latest confirmed descendant function which is one of the biggest pieces of um of the spec. Okay, great. Um and uh about uh related to to the tests to to the testing um we should probably speak

about the test format and for this uh I'll probably just share my screen to be specific and uh yeah to to to um give a context of the things that I would like to discuss here. Let me Yeah. Okay. Do people see my screen? >> Yes. >> Yeah. >> Okay. Great. So for for testing the fast confirmations uh initially thought that it's a good idea to introduce this uh FL start after fast at the station applied um

step here. This this number is the number of a slot. It's not necessary but it's just here for debugging purposes for debugging tests basically. So but it unrised a fair point that this this going to be this step is going to be a part of of the tick. So when when they do on tick they applyations this attestations is uh from the previous slot. Um >> and uh they they do apply uh they do apply at a station on tick deferred at the stations from the previous slot and then on tick also triggers uh this uh

handler. So what what is suggested here is that what is suggested by a ton basically is we move we move these checks all of these uh fast confirmations checks here uh to to the um checks of the on of the tick step and yeah make them optional I think it's fine from the testing format perspective but I would like to understand uh the client perspective of uh how would this be executed uh So do all clients support deferred attestation or not uh in their test runs? I mean of course they supported in the um like regular mainet run but what about the test uh

test runner for the fork choice tests? I'm pretty sure we do support in lower star but I have to double check and confirm. Yeah, got it. Because uh why it is here is basically this attistation is kind of like would be here, right? Um if if if it were a natural. So we have a we have a tick here. Uh new slot starts, we have a block, then we have attestation from this slot. So we we could we could have a we could yield test vectors with this kind of format. But then it means it

implies that the client will in the test runner of the client will defer the satisation and apply it on tick here. If this is the case then yeah we can do it this way because I know that at least in tech um like some time ago uh this uh the test runner of fork choice test did not support uh the forest stations did not do it. Um but yeah, I'm kind of like uh inclined to do it uh uh closer to like the mainet flow and if

we have a concerns from any client teams uh then we'll think about it because Uh yeah, any thoughts on that? >> Yeah, I was just checking into my code and uh yeah, we don't have the support for defer testation in the spec test implementation that we have.

>> M I see. Uh so if if like if there's a way that we can write the format of the specs in a way that it does not have deferred destination that will be much easier to test but like if other clients teams also need it then it's fine then we will update our spec test implementation. Yeah, I see. What what would what would happen if at the station comes uh um like is it just discarded?

I mean the stationation from the current slot it cannot be applied to the fork choice because it's going to fail. But >> I think it's just discarded. >> All right, I see. So we in theory we could send this at stationation earlier >> then do on tick send this at the station once again >> for those clients that do not support deferred atist stations >> and have this uh and then then when when would you call uh slot start after past attestations apply? When would you do this?

after destination applied. >> Yeah. When would you trigger the fast confirmation? Is it going to be a separate step or like or part of tick? >> It's part of the tick, >> right? But then the problem is that the attestation will not be unless the attestation was deferred. It won't be applied because we cannot put it between >> one station and between the tools start after passation applied.

>> Uh I I will double check everything and then confirm you. >> Yeah. Then we'll wait for for your feedback and uh yeah thanks for discussing this. I think it's important and sorry for taking so much time of discussing this specific part. >> No problem. >> All right. Uh so I think it's that's all with the testing updates. Are there any questions? Um, yeah. Thanks, Kev.

>> Do you want to comment on that? >> Um, yeah, I can quickly comment. Uh so in the PR uh Eton noted that the ZK attesters would routinely attest to the previous slot and not the current slot uh just because the proofs take a long time to be produced and for the ZK testers to then receive them in a test. this technically speaking I think is like Byzantine behavior and what we really want is for the proofs to arrive uh within the same slot and for the ZK testers to receive the proofs within the same slot. So you shouldn't be able to

tell the difference between a ZK tester and a normal tester. Uh so to me uh no no change would be needed. Got it. >> Yeah, great. Um, grateful for thanks for sharing the context and more detail on that. Um, to Justin comment, uh, I think time milliseconds would be helpful, but uh, these seconds are there from from the very beginning of, you know, of the having the test format format, I believe.

>> I'm sorry, I missed it. It's because what? >> Huh? >> I'm sorry, I missed what you said. Is it because of the uh existing fork choice? >> Yes. Yes. Yeah, exactly. This is the existing pork choice format. So, it's been there for Yeah, it >> it's not like >> Yeah, I forgot about that. Sorry. >> No worries. Cool. Right. Yeah, unless there are any questions on tests. um and uh maybe the spec as well. We'll move on to the beacon API Okay, let's quickly go over beacon API.

Um so um to give a a little bit of a context initially we'll we have we already have this uh safe block tag in the JSON RPC API. So this uh and this safe block is uh propagated by CL to the EL. So the when we have an implementation of the pass confiration rule and it is enabled uh it's kind of like suppose that uh this safe block will be populated with a confirmed uh block with a hash of the payload of a confirmed block. This is how uh this is how the um confirmed

block will become available at the beginning like from from out of the box. But uh we also might want to introduce and might be useful for consumers uh might be very useful for consumers to have uh to expose the confirmed route um or confirmed state uh in the beacon API. And I was looking into the API uh and we had a quick conversation during uh the um workshop the fast confirmation workshop in Argentina uh where we a bit covered the beacon API. Uh and uh it seems that it kind of like makes sense to introduce

um the confirmed route or confirmed block into the events event stream where like basically a subscriber can subscribe to head uh add station whatever else. So it can be not just had but also a confirmed uh confirmed walk. So whenever there is also like the topics for a finalized checkpoint. So whenever there is a new confirmed block it will basically uh be sent to the subscriber. The other place where it can be added is the block ID. Uh we have uh the head finalized uh as a block ID today. So why not have confirmed here might be pretty

useful. Um and also the other part I think makes sense to have uh we have this uh kind of like uh finalized uh flag for all the data we provide uh over the weekend API. Maybe it makes sense to also introduce this con uh a confirmed flag. So if you query a state or you query a block uh or or or you query whatever data from the beacon API you can see that is this from the confirmed state or not like from the state of a confirmed block or not. So something like that. This this this like

three places that probably make sense. Maybe there are others. Um I'm pretty keen to hear any uh suggestions from that. And yeah, if anyone wants to say something about it, please go ahead. All right, then I think we will get back to this discussion in a couple of weeks.

Um, okay. Are there any other open discussion topics that people want to bring up? Well, thanks everyone then and see you in a couple of weeks. Um, we'll have tests. Let's keep the testing discussion uh offline and uh let's have test as soon as possible and yeah see you see see you in Telegram and Discord.

Hey everyone. Bye. Byebye.