Fast Confirmation Rule Breakout #4

Fast Confirmation Rule Breakout · 3 Mar 2026 · 22:18

Fast Confirmation Rule Breakout #4, held on 3 March 2026. The fast confirmation rule is a consensus-layer proposal that would let applications treat a block as confirmed much sooner than full finality. Tests for the is1Confirmed function were merged with strong coverage, and tests for previous-epoch block confirmation were in progress, with more than 100 tests targeted for the end of the next week.

Speakers

Topics

From Fast Confirmation Rule Breakout, hosted by Ethereum Foundation.

Transcript

Mikhail Kalinin: Ayy. Hey, Will.

Will Corcoran: There we go.

Julian Ma: Hey, hey.

Mikhail Kalinin: Did you learn? Anton?

Will Corcoran: Enjoy. Hey, Antoine.

Antoine James: Hi, everyone.

Will Corcoran: Hey, everyone. Normally start with client updates, we… I don't believe any client devs on the call. Mikal, you had… Added these spec changes that you wanted to discuss, Is that something you would want to talk about at the top of the call, or are you hoping to have more of an audience to… Review those changes.

Mikhail Kalinin: I would just go quick over the new change, and… on the call. So, basically. Yeah, they request us to review the thing, but yeah. Should we do it now? Sorry, can you hear me?

Will Corcoran: Yeah, we could… We could wait another couple of minutes before we start, if you want.

Mikhail Kalinin: Yeah, let's wait.

Will Corcoran: Okay.

Alright. Thanks, everyone, for coming. This is Fast Confirmation Rule FCR breakout room number 4. We normally start with client updates. I don't see any client devs on the call, please correct me if I'm wrong. But Mikhail had a couple of spec changes that we were gonna start with. I will drop the… Links in the chat, and Michael… If you wanna take it away.

Mikhail Kalinin: Yep. Thanks, Will. So… Yeah, the first one… Was the, the fix for the edge case found by Ethan from Nimbus? This is, like, the edge case with the first block in the reconfirmation part of the spec, so that's the spec issue. It's addressed, there is a test already written to cover the such case. Great credits to Ethan for finding this out. Also, there were… a side of… the second change, the second change is about, Yeah, it's just, like, the most recent one. So… This changes the way we compute the adversarial threshold for like, the adversarial wait for the, compute and honest FFG support, for the honest FFG support that we have.

It's kind of like, this PR, this change, introduces, like, a similar way of processing locations, so a similar way to is1Confirmed, method. In is1Confirmed, we have this, discount for validators who already equocated. We discount these from the adversarial weight. So basically, if, like, say 20% of letters got slashed, we assume that honest validators never slashed, and we basically subtract these 20% from the 25% of the potential adversarial weight, which basically increases the liveness of the FCR, without compromising security. So this was, from the beginning in the spec for ES1 confirmed, but it was not for this honest FFG support. And now they are similar, in that regard, so that's basically it.

what's left to do is to fix tests. Some of the tests are broken by this change, but yeah, just please take a look and be aware of this change. I hope this… this is, like, one of the last changes to the spec. Except for potential issues with the spec or box, but… Yep. That's about it. There were a few changes that also landed the main branch after the previous call, and also we were, after the previous call, we were exploring Damn. The… the way of, like, reusing fork choice weights in the first confirmation rule. But after, like, some conversations with developers. We decided not to do this, and because, yeah, it's… it's not possible as is to reuse the fork choice weights, and will require some additional tweaks.

And also, the positive thing is that, if the fast confirmation rule implementation is independent on the FOC choice. So these two components can be changed independently, and yeah, the work can happen in parallel. So we decided not to do this. And, yeah, this back is moving towards, like, its final state. That's it about this track.

Roberto Saltini: So, Mikai, do you mean that we… We can new… we can compute the fork choice… sorry, the… The, yeah, the fork choice waits for the fast confirmation route using The violence is coming from this. any checkpoint. No, not just… Not just considering the… Most recent justified checkpoint.

Mikhail Kalinin: Yes, yes. So that's… That's my take. So we can use, like, not arbitrary, but a different balance source for the fast confirmation that we use for the fork choice. This whole thing.

Roberto Saltini: I used it. Yep. Can reach that checkpoint that we intend to use originally, which is the… Credit has justified? at the beginning… at the beginning of the last slot of the previous epoch.

Mikhail Kalinin: Yep.

Roberto Saltini: Okay. That's good from a… Okay, algorithm point of view. So that's the… Ugh. Lion, lighthouse implementation of the first confirmation rule, implement this. the algorithm, as we had, like, in the paper, were usually justified from the… Last slot of the previous ebook.

Mikhail Kalinin: Yeah, I think so. To be more specific, it's, like, in the spec, but the spec is, like, this… yeah, the spec is very close to the paper. So, yeah, I think that implementation, I believe it uses the algorithm as… In the spec. Well, sorry, in the paper.

Roberto Saltini: Okay.

Will Corcoran: I just dropped a link to the Lighthouse implementation Roberto was referring to in the chat. Great. Any other updates? Spec-related, testing-related, research-related? Or discussion topics. On the paper side, We're resuming work after a short pause last week. Tomorrow. I will have a meeting with Roto to plan the next steps towards finalizing it. Thanks, Luca.

Mikhail Kalinin: On the testing side… we had… Yeah, this… let me link to the PR. This is the PR with the… is one confirmed function test. Made by Luca, it has a… quite good coverage. Also, currently, we are working on the… Like, rigorous testing of the cases where we need to confirm the block from the previous epoch. To… to… to remind, we have these… we have… I see a similar test suite done for the current epoch blocks. Now, the previous epoch block case Okay, all cases need to be covered. So it's like… I would say more than a hundred of tests to be… finished soon, so… Yeah. The goal is to have them done by By the end of next week, something like that.

And, after this is done, it's like, it will be, like, 90% of test coverage, maybe 95% will need, probably, to try to cover some edge cases and some More than 100, yes, for this particular stuff, for this particular, previous epoch block test. So we, we currently have, like, around 100 tests. Maybe something like that. Yeah, and a good test coverage will allow us to, to say that the devnet implementation that passes all the tests, if it passes all the tests that, He'll give us some… Assurance that it's likely correct.

Will Corcoran: Great. Any other topics? Alright, well, we might just… have, A short call today. And… that's okay. Seems like we're making a lot of progress, on the testing. Cover side, the research is about ready to wrap up, and on the specification side, so… Seems like things are all moving in a positive direction, and… yeah, I'm sure we'll start getting more client, participation as things… I know that they just hit, DevNet Zero with ePBS. So there's probably a lot of effort focused on that right now.

If there's nothing else, I say we call to call.

Roberto Saltini: Thank you.

Will Corcoran: Thank you.

Mikhail Kalinin: Thank you.

Julian Ma: Thank you.

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