Fast Confirmation Rule Breakout #5
Fast Confirmation Rule Breakout · 17 Mar 2026 · 28:49
Fast Confirmation Rule Breakout #5, held on 17 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. No client developers attended this call, and tests for previous-epoch blocks were targeted for completion that week.
Speakers
Topics
From Fast Confirmation Rule Breakout, hosted by Ethereum Foundation.
Transcript
Mikhail Kalinin: It will.
Will Corcoran: Hey, how are you?
Julian Ma: I will.
Luca Zanolini: Hey, guys.
Mikhail Kalinin: Adrienne?
Will Corcoran: I'm just sharing this around a couple places real quick. Yeah, for some reason, the… One that the… there's, like, all these automations when you create an issue in the PM repo must be broken.
All right, well Sorry for the, checking hole hiccup. Let's, make do… So… I don't… there's no client devs on the call, so normally I start with client updates. I don't know if… Anyone has any updates on the implementation side, or if we should just jump to spec updates? Alright, let's do it. Mikael, was there anything that you wanted to kick us off with?
Mikhail Kalinin: Yep, sure, so… Since the last call. we have merged this PR, With the test fix. This is, like, should be, As expected, it should be, like, the last substantial change to the spec. Except for potential bug fixes. And, yeah, the last one before we finalize the spec and actually merge the spec PR. So the next one I'll share now… This was the refactor, and there was a follow-up fix, because this refactor introduced an underflow. found by Eton from Nimbus, so there was a follow-up commit with the fix, basically adding a safeguard, for potential underflow. And yet another thing to share…
Yeah, the last one was, like… I was… yeah, the last one is the bug fix for… for a discrepancy that was in the spec since the beginning, also noticed by Eton. So I would not go into, like, all the details. I think the PR is kind of, like, say, self-descripted, but just wanted to say that, we had, three, changes in this pack. And implementation is those who already have implemented, all these pieces of SPAC should just be aware of those. And… Yeah, just, you know, catch up with those changes. On the spec side, I think, From my, my perspective. The spec looks good, and there was a decent amount of the feedback incorporated in the spec already. And the goal is to finalize the spec in the next couple of weeks.
So… I'll be working on towards, towards finalizing it. And all the follow-up bug fixes, if they will appear, and Yeah, and all the, follow-up edge case testing, they can be submitted separately. So there is, like, some… Homework to do with the spec itself, to update the test format. And, to fix Gloas tests, they're just failing, because the Gloas has updates to To the fork choice functions that's used by the tests. So they need to just cut up with those changes. Yeah, that's… that's the goal, finalizing this pack in a couple of weeks. And, with respect to that, I was just gonna ask if we should double-check That we are all okay to do, to merge the PR in a couple of weeks.
One of the problems I see here is that some of us will be on EthCC. by that time. So we could probably do this asynchronously.
Will Corcoran: Yeah, That is a good point. I was actually gonna flag that, as probably something that'll cause me to miss the next breakout room, and perhaps we could just cancel it, but… With regards to merging that PR at that point in time, are there… I guess… Are there, like, heightened concerns that come along with that, that you would like to be… at your home base in order to do that work? If so, I don't see any harm in that waiting another week until you're back from EthCC. And just… Out of curiosity, could you explain what you mean by underflow?
Mikhail Kalinin: I was just, like, the, Sure. So that PR introduced, a subtraction operation, so we just subtract, Some of the value from another value, and when the the value that we subtract the thing from is lower. It's gonna basically underflow, and since we use unsigned integers, it will take, Arbitrarily large value, instead of, like, Just return 0. So the safeguard is basically to return zero, when… when… before, you know, doing a subtraction in this case.
Will Corcoran: Excellent, thanks. Was there anything else on the specs or testing front? Any questions about, the roadmap. Between now and merging that in.
Mikhail Kalinin: I can add on testing. So, for these PRs, I've added points to the test plan. So those, are… some of the… there are some corner cases that we want to cover with tests. The current, testing effort is at, In the progress on, like, I would say in the middle of, Having the previous block test that, was, like, announced a couple of weeks ago. I'm aiming to finish it this week, basically. And this is also… Yeah, and this, this also, like, this, previous factor, previous block… previous epoch block tests are… Gonna be a part of, you know, the… of the changes that we are about to merge to the consensus fact, so this is one of the… on the critical path to merge this PR, I think. Also, I published,
The test vectors, they all already include some of these previous, block tests. Yeah, and Lighthouse and Lodestar seem to run them well, so both tests make sense. We'll just keep to… keep… keep focusing on it, till the end of this week, so should… should be up. Should be an update with the new test vectors after that. Answering Jihoon's question, do we need to handle that on the flow case, or is it just returning zeros sufficient? I think returning zero is sufficient in this case, in this particular case. It would be great to have a test for it, so… but we can write it later on.
Will Corcoran: Excellent. Do we anticipate any… new tests… needing to be written out of the finalized research work that, Luca and Roberto are working on.
Mikhail Kalinin: No, I think we're fine, like, with the… like, the algorithm in the spec is at its final state. So, basically, testing doesn't depend on That research paper. Correct me if I'm wrong.
Roberto Saltini: Yeah, yeah, yeah.
Luca Zanolini: No, no, yep.
Roberto Saltini: moment is… Yeah, it's more on, improving the… The readability of the paper. Just trying to provide a sort of soft… Introduction to the… Into the series of lemmas that approves. Yeah, so no change to the algorithm at the moment, and no change for seeing either.
Will Corcoran: Awesome. so, I don't know if there are any other… Testing… spec, research-related. Topics, that anyone would like to bring up? I know that, Julian, you had, reached out to Mercy, I believe, about, RCP-related conversations. Is there anything that you would like to say there?
Julian Ma: So… Yes, I reached out to Mercy Indeed, and I saw that Mercy posted an agenda for the next RPC standards call. It would be great to present it there, just so that RPCs are aware. They basically don't need to do anything, but it's good for them to be aware of it for when their customers come to them, and eventually it would be nice if they could, like, speed stuff up as well, so… In speaking with one of the bridges, they mentioned that RPCs could start competing on who is, like, the fastest to be able to fast confirm a block if you're better connected to the network. I think this could become interesting, maybe with ePBS, as, like, attestations come earlier in the block, for example.
Will Corcoran: Great, it looks like that, next RPC call is next Monday? Good.
Julian Ma: It's on the 23rd, I believe.
Will Corcoran: 3PM UTC.
Julian Ma: Yes.
Will Corcoran: Great, and in case you missed it, we shipped a really fun little website yesterday, fastconfirm.it. And… Yeah, I think pretty much… Several of the people on this call, lent a hand in bringing this to market. I think it's looking really great. Seems to be getting some… some real positive, feedback, and… Yeah, I'm just real happy with the way that, we're kind of parallel processing so many different things, and I think it's gonna help Like, really, Accelerate the feedback loop and make sure that we're getting adoption, and the markets kind of… seems to be, very excited for this to ship, so… I think. April, May is gonna be a lot of fun, getting this rolled out. So, yeah, Julian and I have a call to action on the website to… to get in touch, and it leads people to an intake form, and we've already started having
some calls, and Julian's been doing a fantastic job, like, explaining all the mechanisms and value props to all these different user types, and that has, in turn, been helping make us aware of some… Additional opportunities for people to reach out to, and just get a better understanding of, like, ecosystem-wide How this, needs to be rolled out. Is the FCR spec, like, an ad hoc to the CL spec? In other words. is it unidirectional from the LSpec to FCR? Sorry, I just skimmed it. But that's a great question. So, yeah, I don't know, Mikhail, if you want to note on that, because it's not, it's not a hard fork, it's not consensus-breaking code. Any thoughts on how that gets, merged in or adopted into the
The beacons back.
Mikhail Kalinin: Yeah, that's a good question. So, currently, This pack is kind of, like, pretty much independent, but, for… For the algorithm to work, we need to keep around some of the variables. like the, the head of the canonical chain observed at the beginning of the previous slot. And, a few others. And for this, we, currently, this pack extends the Fok Choice floor to keep those variables there. So it kind of, like, modifies the spec in this way, but this is, Backwards and forwards compatible changes for other… Hard forks. For instance, for clause, but it should be also, kind of, apply to other artworks. And the other piece of this… the consensus spec that is changed is the… there is a tiny bit of, of the spec around the safe block hash.
The one that the CL uses to pass to the EL. So this also changed to, basically use the confirmed talk. Yeah, that's… That's, like, the answer. It's kind of, like, sep… Independent, but, like. It's standalone, but there are some. Small dependencies.
Will Corcoran: Curious, can anyone think of an analog? features. You know, something else that's not… Consensus breaking, but exists within the consensus spec like this, or is this sort of a unique… one-off.
Mikhail Kalinin: I can't say about the feature itself, but in terms of the spec, speccing out, there are… there is a, Week subjectivity period, it's stuck. Which is… Stand alone. But, weak subjectivity is, like. An implicit property of the protocol, so that spec is just there to do the computation. According to this big subjectivity model, but yeah. But the feature that can be, you know, consumed by users, I don't know, I'm not aware of.
Will Corcoran: Mercy's asking, how should our PC providers communicate the security difference between a safe, fast confirm block and a finalized block to downstream customers, especially those in high-value use cases like exchanges or bridges? Julian, any thoughts there? The best way to… Communicate that nuance between fast confirmed and finalized.
Julian Ma: I think… like, every time that we communicate faster information rule in depth, we say about the assumptions, and usually we do compare it to finality as well. So I think for those implementing it, it's quite clear. Like, maybe publicly, it's… Somewhat less clear, I know, we could just say it's a confirmation rule with different assumptions. What's, like, the forum in which you're thinking about the… expressing the difference? Maybe I missed that.
Will Corcoran: I guess Mercy was asking, how should RPC providers communicate the security difference? And maybe this is something that you could just, speak to on Monday.
Julian Ma: Yeah, that would be good. I think what would be helpful is that they could point to the website, where the security differences are explained. Mmm… Yeah, maybe I could speak more to it on Monday, yeah. Thanks.
Will Corcoran: Great. Any other discussion topics, or blockers, or timely items that… Folks would like to… to discuss?
Mikhail Kalinin: I was actually going to raise a topic on standardizing metrics that I introduced by Lighthouse. That will help, will be helpful for… Performance measurement across different implementations. So, I'll just probably drop a link to the chat, but also, Yeah. Since there are no… depths here. I'm just wondering if anyone is aware of the best way to, you know, to introduce those metrics, like, into the CL metrics that we already have.
Will Corcoran: You might… do you know, Katya?
Mikhail Kalinin: Yeah.
Will Corcoran: You might want to ping her. She's been instrumental in leading sort of client… agnostic, metrics in the lean consensus, calls on PQ Interop, and she was also leading, that effort for Peerdos at one point in time. So there is a… a precedent, and she's as knowledgeable on the… on the topic as anyone.
Mikhail Kalinin: Awesome, thank you for the contact. Yeah, also, it's for us all, and for developers to think about which of, not, like, all metrics that I in Lighthouse might be standardized, but the most, like, meaningful, the most reasonable one should be. So, it's like, to decide on the actual list of metrics that we want to see in our clients.
Will Corcoran: That's great. So do you, is it… would it be… Enforced, almost, like, where you would have… Like, a test to determine whether or not the spec is implemented, or the metric is implemented.
Mikhail Kalinin: I think it should not be kind of enforced, but it's rather, like, should… the client shouldn't implement this. Hmm, so… Yeah, I believe we cannot enforce doing that.
Will Corcoran: But yeah, great idea, I think that would be very helpful.
Mikhail Kalinin: Yeah, but if client is about to implement some metric. We will have a standard for this, so it's, like, really the same metric in all clients, and it's easy to monitor. Different clients on the same dashboard, if metrics are standardized.
Will Corcoran: Excellent. From Jahoon, I think we should consider what users would be interested in for the metrics. Yeah, that's something that we can, start to… ask in our… our, sort of, intro conversations that we have, Jahun. Mercy.
Mercy Boma Naps-Nkari: Sorry, I just wanted to add, it would also be good to know what you want to test, for example, what you want to see on the metrics itself. The things you want to measure, per se.
Will Corcoran: and with… the next call coinciding with EthCC would people be opposed to me cancelling that call, as I'll be out of the office? If not… Happy to let the call run, and if someone else wants to lead the call. Cool. And then, Mikhail, just so you're aware, Julian and I met with, Nuno from the Digital Studio team of the EF last week. And, we're trying to get some… Some booklets printed out so that we can have, those on hand. I know you'll be in Cannes, I'll be in Cannes. We could divvy them up when we get to Cannes, and they could be… Valuable information, you know, for people during conversations, and hopefully direct people to the… to the website.
Just helps spread the word.
Mikhail Kalinin: Great.
Will Corcoran: But if there's nothing else, I think that's all I had. Plan to cover for this, for this call. Is there a list of clients? By clients, do you mean CL clients or potential users? If you… Right now, Mikael, did you see the, link that I posted earlier, this dashboard that, that John Church from… NetherMind, created that's tracking the implementation of the clients. This is showing Lodestar and Lighthouse. as, having… Implemented or enabled support for… Best confirmation rule.
Sorry.
Mercy Boma Naps-Nkari: I was… I was sorry, I was just looking for the specific branch, where the code is.
Will Corcoran: Or… any client?
Mercy Boma Naps-Nkari: Yeah, for, like, Lighthouse and then Lost, I think that's the ones I've seen so far, but I don't like where the actual code implementation is, not the dashboard.
Will Corcoran: If you go to the, the GitHub issue for this call. There's a table in the top of the issue, and I try to link to the code the active PR, for each team. Alright, well, thanks all.
Mikhail Kalinin: Thanks, Will.
Roberto Saltini: Thank you.
Julian: Thanks, Phil.
Luca Zanolini: Thank you, guys.
Transcript adapted from ethereum/pm, CC BY-SA 3.0.