Fast Confirmation Rule Breakout #6

Transcript

Mikhail Kalinin: Hey, Barnabas. How are you doing?

Barnabas Busa: Struggling with ePBS. That's probably everybody else.

Mikhail Kalinin: Yeah, I see.

Barnabas Busa: What about you?

Mikhail Kalinin: Yeah, glad that you joined, regardless. I'm fine, thank you. I'm just, you know… Looking forward to merge the fast confirmation PR to the SPAC. Which is quite kind of radiant, we just need to do a final… Review on it.

Barnabas Busa: I haven't really looked into it yet, that's why I also joined the call.

Mikhail Kalinin: Oh, that's great.

Barnabas Busa: And this is all just an optional thing, right?

Mikhail Kalinin: Yeah, it depends on the implementation, though. For instance, in Nimbus, they have, Already released this feature, and it's by default enabled, and you cannot disable it.

Barnabas Busa: Oh, interesting.

Mikhail Kalinin: Yeah, so that's just, you know, implementation decision. But it's on top of the protocol, it's not on the critical path to consensus. So I… I don't know.

Barnabas Busa: Which one's the open PR? I'm checking the agenda and can't see it there.

Mikhail Kalinin: Yeah, let me… let me just share it. Here is the PR. I'll drop the link into the chat. It was a long, long journey, on, you know.

Barnabas Busa: Oh, wow, yeah. Since November.

Mikhail Kalinin: Yeah. So… IU… Do you feel ready for the interop? I mean, like, do you feel that client implementations are ready?

Barnabas Busa: No. Nowhere near. Yeah, we're still behind. Yeah, ideally, ideally, we should have ePBS.2 up by this week. It's just not gonna happen. I do consensus pack change, to remove this double estate thing, from Nico. I think that's a very good change.

Mikhail Kalinin: Yeah, I see, I saw it.

Barnabas Busa: But by the time it gets merged and, you know, we get a new, spec release, everything just takes time. Clients would love to rip it out, their implementation, and particularly redo it. And they have to test it, merge it, that's just gonna take a long time.

Mikhail Kalinin: Yeah, I see, I see. Yeah, I can feel that. Okay. Anyway, so interop, gonna be quiet. Useful venue for, you know, quite helpful to… to get everyone in sync.

Barnabas Busa: Yeah, so I really do want to have the Amsterdam desktop, The first days of… Interrupt the test.

Mikhail Kalinin: Sorry, what was it? Amsterdam Testnet, or devnet?

Barnabas Busa: Like, the first .NET, for… Where we merge all the block of access list stuff as well.

Mikhail Kalinin: Oh, yeah, I see, I see, yeah, that's gonna be huge.

Barnabas Busa: Yeah, it depends on when this gets merged in. It can also be an optional thing already on top of it.

Mikhail Kalinin: Let's see. Anyway, good luck with that.

Barnabas Busa: Oof.

Mikhail Kalinin: Hey, roll. Antoine, Roberto, Mercy.

Will Corcoran: Yo.

Mikhail Kalinin: Hey, Luca.

Luca Zanolini: Hey, guys.

Will Corcoran: I guess we could give it another minute. I don't know if, anyone's been in contact with any of the… Client devs, if they're planning to come, or if, this should be the group. to expect. Mercy.

Mercy Boma Naps-Nkari: Yeah, I just wanted to notify you guys. I'll be representing Glendon. I currently have a working PR for FCR.

Will Corcoran: Awesome, thank you. Alright, well, should we get started? Mikael, Or maybe, Mercy, do you want to start with a… we normally go with client updates first. Do you just want to give us a lay of the land of where Grandine's at with things?

Mercy Boma Naps-Nkari: Yeah, so we've… we have, like, a PRR which implements FCR in gradients, so… it also has the validated end-to-end against Lodestar in a live devnet, and then… Also the update on the specification side, which has to do with tightening the FFG conflict check. for street inequality, and then, the division and community with safety adjustments, I've also, like, implemented it, which I ran a devnet which criticisms using low star grinding, and then gets… the two clients agreed on, the same, confirmed route, so… So far, so good.

Will Corcoran: Good to hear. Any questions or blockers, with the rest of the implementation?

Mercy Boma Naps-Nkari: No, I think I'll just have to pick up, as we go on.

Will Corcoran: Awesome. Mikhail, do you want to… I know that you've merged in a lot of work with the specs. I'm sure you've got a lot to provide updates on. I also know that you tend to have pretty good context on other client teams that might not be on the call. Maybe just… do you want to give us a… An update from your perspective?

Mikhail Kalinin: Yeah, but yeah, first, just a question about Lodestar to Mercy, is it already in Lodestar's master, or is it, like, you run a branch with that implementation?

Mercy Boma Naps-Nkari: Yeah, there is a branch by NASA, it's still a drafts branch, I think. I had to, like, check it out and build a local image of it. I was trying to build from, from Nimble's branch, but the Docker image, I was having issues with it, so I just had to, like, work with only Lodestar, the branch NAS I was working on, and then… My own branch, also.

Mikhail Kalinin: I see, okay, thank you. Will, do you think we should, continue with… start with the spec? Or just share some client updates as well.

Will Corcoran: I think starting with the spec. would be best. I think, yeah, that's probably where… Being work that you've been doing directly, and then if there's any, like, other observations about client updates that you want to share, that'd be great, just to, like, help socialize, the status for everyone else.

Mikhail Kalinin: Alright, cool. So, on the spec side. I'll probably start from the end, from where we are, from the current status, and then we'll go through the recent changes that we had made to the spec. Just to, you know, announce them here. So, the status of the SPAC, it's on the final round of reviews, Now? And, we made a decision to… Yeah, there is no gloss support yet, in this spec, in the current… in this VR, and we decided to first merge this PR. And then come with, with another PR that actually will… Make bus confirmation gloss compatible. The reason for that is, that The clause… Implementation introduces some… Some backwards incompatible changes to the Fuoc Choice abstractions.

So we need to sort this out in the first place, and then update fast confirmation rule. You know, to… to make it, Basically, work with those new abstractions. So that's the status of the spec, and yeah, let's probably go with… the recent changes, but I see a question from Barnabas. Any reason…

Will Corcoran: Burnabas Nitpick. But any reason why confirmation Byzantine threshold is a config and not a preset? Do we expect to tune this value in devnets, or should we assume that it's going to stay at 25 going forward? In terms of the adversarial threshold.

Mikhail Kalinin: Yeah, actually, it's a configurable parameter, so the algorithm can work from, you know, with these thresholds, starting from 0 to up to 25%. The 25 is the max, the 0 is the main value. So… Theoretically, someone can actually override this config parameter. If that user, that consumer of the fast confirmation rule thinks that, you know. 15% adversarial threshold is fine, or 10%, so… Yeah, and yeah, reducing this threshold affects safety, so you have a different assumption on the adversarial power, but also it improves, Liveness, in terms that the potential delay, potential confirmation delay, can be reduced with the lower threshold. So… That's why it's kept in, you know, in a config, rather than preset.

All right, so… Quickly going over… The recent… Changes that we had made before, you know, since the last time. We had a call, so… Yeah, but test analysis is around 25, so we are quite conservative on that. And, yeah, we actually… Stick at 25, and, you know, like, when we are talk… speaking about delay. We also consider the 25 threshold. Like, we do analysis… delay… analysis of confirmation delay, so, yeah. All right, so the first… yeah, there is a number of changes, so I'll try to be quick. This one is, like, basically… Switching from strict, from greater or equal to one-third to strictly greater than one-third.

And we'll no conflict and checkpoint be justified. That's the, like, the correct… Strictly greater is the correct one, the previous, like. computation, the previous comparison was just incorrect. The PR has a description on that. So… I don't know what to add to here, add here, so here is the other change. To the restart conditions, we previously used justified Justify Checkpoint eBook, so we used the, Justify each point observed at the end of the previous epoch as a starting point, or restarting point. And in one of conditions, we checked, the epoch of the checkpoint itself, But it could… But the block of that checkpoint could be from the epoch we go, if we have, like, an empty slot in the first slot of the epoch from which this checkpoint is.

That could cause further issues, downstream issues, like with the… Well, actually, it could lead if, you know, if this is the case, and the block is from… not from the… Is older than the, Checkpoint epoch? Then we'll get a restart, like… sorry, fall back to finality at the next run of the fast confirmation rule. So, now we check, the epoch of the block itself to… to start from… Per merge, like, from… to have a stronger starting condition and not falling back. Right after it. Yeah, the next one is, like, a small adjustment to the, Adjust committee weight, estimate, computation. It's… it used floor before, now we switched to seal. Because it makes more sense, basically.

The next one is the, change. like… It's more… it's not a change to the algorithm, it's more a change to how the… the store is manage it. We introduced the fast confirmation store to actually Split to actually have a… Even less dependency, in the main spec. like, on the FCR, and vice versa, so FCR, like, this change. Makes no changes, introduces no variables to the store itself, to the folk tree store. Which decouples the spec, the fast confirmation spec, and just makes things cleaner. And implementations are free to… to do whatever they want, with the store, so they, yeah, can take this, path, or extend the store, the forkture store, either would work. Yeah, and the last bit of changes was about optimistic sync.

We have this in the merge, it helps to sync a client, while EL is get… getting up to speed with the, head of Canonical Chain. And, Simply, simply… in simple words, we don't want to… confirm, a blog that was not yet validated by the EL. So, this PR, this last bit of changes, introduces, like, a notion of optimistic sync, and basically, Says that, do not, yeah, do not confirm a blog that hasn't yet been proved to be valid by the execution layer client. The CL spec is not aware of the Optimistic Sync, it's, like, a different thing. It's kind of a side. And, the main… the executable part of the fast confirmation rule spec is not aware of it as well, but, you know, this comment will help to…

To pay attention to this, this part. So that's… that was the changes.

Will Corcoran: Nice work, Mikael. And if anyone's listening, yeah, all these, PRs and links from the chat will show up in the forecast notes, and so you can find all those individual PRs.

Mikhail Kalinin: Cool, and, yeah. Regarding the, other client updates, haven't Nimbus released their fast confirmation rule implementation? Let me share the link to the release, which has it. So it's, like, already a… Already in place So, Nimbus users can start… Benefiting from fast confirmations already. Which is great. Congratulations to Nimbus team. Great work. Also, I would like to encourage everyone who is interested to go to the PR. Look at it.

Probably find time to review it. We need more approvals. To get this… to get it merged, and more eyes on it now. And also, yeah, especially, specifically from client implementers as well, that'd be great. To get approvals.

Will Corcoran: That's great. And then, are you able to speak to any of the The backtesting and additional analysis work that's been going on, I know Sam from PandaOps is working on that, Anton from Consensus and Jahoon has been doing Some benchmarking. None of them were able to make this call, but if you… I don't know, have a sneak preview of any sorts that you want to communicate in terms of what's being worked on, that'd be… Interesting for some people, I would bet.

Mikhail Kalinin: Yeah, I can do a quick summary. So basically, there was, Sam and Anton, worked, independently on, and they, took a bit different methodologies to Basically, do analysis on the post-confirmation delay, so how much So we usually, in the best case, we get confirmations in one slot. And the goal of this analysis was to figure out How frequent we get confirmations delayed, like in 2 slots, 3 slots, and 4s. We did this before, so… If you look at the PR, There is the performance measurement as well, there. And, Anton and, Sam were, looking at different, A different span of times, a different span of epochs on the mainnet. We're… as far… as far as I…

As far as I recall correctly, Anton was running for about a month's period. I know what Sam is about the same. At the same run. And the numbers that they get are pretty much, pretty close to those that we have, in the PR, description? Yeah, that's what I can share, which is great. More on that will be shared. In the future. Not distant future. I believe. So that's kind of, like, the update on it.

Will Corcoran: Excellent, very cool. Yeah, hopefully we can, share some of that on the next breakout call. Or the one after. Roberto, Luca, anything that you wanted to… throw in, in terms of, I know you've been finalizing some Some proofs in, in an updated research post. I don't know if there's any updates there that you wanted to give?

Luca Zanolini: Oh, yes, the paper, as we mentioned, is done from our point of view. We are… we share the technical paper with someone, and we are gathering Very important feedbacks, very interesting feedbacks, and we will then address all of these feedbacks, and… ideally then soon release this, this paper. And, yeah, so everything is going actually very well. We… we got Great reviews. So, yeah.

Will Corcoran: That's great. And then maybe just… for people's awareness, Mikel, Luca, do either of you anticipate that once that paper is done, that it would then, sort of cause revisions to the spec? Or, Michael, do you believe that the spec is Like, pretty well baked at this point.

Mikhail Kalinin: I think the spec is… If it's final. version, so I don't expect any changes. For this pack, so far. Yep, so, you know.

Will Corcoran: Fantastic. Any other updates or discussion topics that… Folks might have. Alright. I think maybe that… does it for this call, and we will be back for FCR Breakout Room 7 in 2 weeks. What's the holdup on merging the sun, barbecass?

Mikhail Kalinin: So… So we're… review by Justin. And, yeah, his points addressed. And we also… we are also waiting for approvals, from… from client developers. That's… that's one of the things. Yeah, the other one, like, is just, you know, get approval from Justin.

Will Corcoran: Alright, sounds good. Yeah, hopefully all that resolves itself here in the next couple weeks. Mercy.

Mercy Boma Naps-Nkari: Sorry, I wanted to ask, do we have, like, client images that, we can use? I only have, like, Lodestar. I'm unable to use, get other images from other clients so that I can properly test, although the… definite criticism I did. came out well, so… but I just want to, like, increase the clients and then see what happens.

Will Corcoran: I don't know the answer to that question.

Barnabas Busa: It's good.

Mikhail Kalinin: It's a good… Yep, burners?

Barnabas Busa: Sorry about that. Kendra? That Rikal already posted. I think that's true, that one.

Will Corcoran: your audio's a little garbled, Barnabas. But it sounds like… You're referring, Mercy, to the PR from Nimbus that Mikhail already posted?

Barnabas Busa: Yeah, exactly.

Will Corcoran: Okay.

Barnabas Busa: Does my sound a bit better now?

Will Corcoran: Yeah, it is. And then… Antoine had asked in chat, do we have a time frame for when to expect client teams to have FCR implemented after merging it. I'd also like to start reviewing client implementations. After merging the spec, I'm guessing.

Mikhail Kalinin: Yeah. So… We actually have, Ready to go implementation, and… Lighthouse, and I believe in Lone Star as well. My gut, I can't speak, on their behalf, but my gut is that, they just… they're just waiting for, probably, for the spec to be merged. to… to… as a signal, you know, for… yeah, that's… that's the final one, and we are ready to merge the implementation as well, but probably there are some other reasons that are holding them from… holding them off from merging the APRs. Yeah, Barnabas, that's a fair comment, yeah. There is a lot of work on the ePBS in progress.

Barnabas Busa: Yeah, I'm just a bit worried that if they start merging this, they might have some conflicts with their ePBS implementation. And maybe that's why they were also not, do proactive. Yeah, everything else seems to be on the… Back burner. When it comes to implementing, Chances. But yeah, I think once the PBS is pretty stable, then all these, side projects can take, President, again. I think there will be a few more, not just FCR.

Will Corcoran: Or am I… was the goal for ePBS to have net zero at Interop, or have they already, reached that?

Barnabas Busa: Yeah, we already are done at 0 and then at 1, and then at 2 is, sometime next week.

Will Corcoran: Okay.

Mikhail Kalinin: Also, I've heard about Prysma implementation as well, but… It's work in progress. So, and I believe here, with Prysm, we have, you know. the ePBS, like, is the highest priority for all teams, and for Prysm as well, so…

Barnabas Busa: Yeah.

Mikhail Kalinin: One of the reasons that, like, why they don't have the FCR implementation yet.

Barnabas Busa: Do you expect to have a glossary-based version as well, soon, open for the content spec?

Mikhail Kalinin: Good question. I hope so, but… Not… not really, because before we do these. I would like… before we open up the FCR, APR to the FCR to make it compatible with clause. I would like to revisit some abstraction changes on the main spec. So that's on the critical path to it. I… I see some of the, ways to improve. the Foc Choice spec in loss. So, I don't know, it will take time. It's not going to be soon, definitely. And for the FCR itself, it's, there will be a change as well. I guess… Like… Because we can confirm a payload from the current slot and some… In some cases. In most of the cases, these payloads, the confirmed payloads will be from the From the previous slide. So…

Sort of this. thing. Like, not from the previous, sorry, like, from the previous slots in some of the cases, and from two slots ago in most of the cases.

Barnabas Busa: Can you talk a bit about the fractures changes that, you're planning to do?

Mikhail Kalinin: It's just basically… yeah, it's just basically… you know, may get had To work, you know, to not introduce, like. backwards incompatible changes, because now get had in gloss. has a different signature. It returns the book choice node instead of root, as it was before. Which actually makes, you know. Specs like fast confirmations, I know that probably just one fast confirmation spec, that depends on the main protocol. It's… it makes it… Work-aware, so we'll have to… In terms of, like, abstractions, so we will have to distinguish between One and the other. In this bag, which is not good, I think. So, sort of this, you know, no, no, like, no changes to the semantics, no design changes, but basically changing the spec itself, how it's written.

Barnabas Busa: Okay. So, no actual spec change from plan… plans. Point of view, right?

Mikhail Kalinin: Right, right, no semantics changes, it's just, you know, this back, I think.

Will Corcoran: Alright, good stuff. Yeah, I believe that probably does it for this week, and… See you guys all in another week? Or sorry, in two weeks. And Mikhail… Antoine, Luca, Julian, and Roberto. I'm gonna drop a link to another meeting room for us to join to talk about some administrative items. See you soon. Thank you.

Transcript adapted from ethereum/pm, CC BY-SA 3.0.