Fast Confirmation Rule Breakout #11

Transcript

Mikhail Kalinin: Hey, Lion Dmitmitrii.

Dmitrii Shmatko: Haha.

Lion Dapplion: Unlimited.

Mikhail Kalinin: Sorry. Morning, everyone. Let's give it, like, 2 to 3 minutes more for people to join, and then we'll start.

Lion Dapplion: Is it better now?

Mikhail Kalinin: I can hear you well. Can you hear us?

Lion Dapplion: Yeah.

Mikhail Kalinin: Great.

Lion Dapplion: And now…

Mikhail Kalinin: Yeah, now I can recognize your… your voice. It's even better now.

Lion Dapplion: Then there's… Headphones are pretty bad, likewise.

Mikhail Kalinin: I see. We don't have a Discord. channel, dedicated to FCR. We have a Telegram group. And if we want to discuss it on Discord, I would suggest to use One of the channels that we have. Maybe… We'll stay Consensus 1 is the best.

Alright, let's go ahead and get started. Everyone, welcome to pass Confirmation Rule Breakout Number 11. Here is the agenda. So… We'll start as usual with client updates, and I will start from… Newcomers today, so… Let's start from Lighthouse.

Lion Dapplion: I guess this is the first time I joined, so… well, we merged FCR. So I guess we're done. Not sure what else do you want? I had some questions, but we can do them later.

Mikhail Kalinin: Yeah, do you want to share any, highlights, from… from your… I mean, like, from the work on your implementation, any… anything else related to the spec or whatever?

Lion Dapplion: Yeah, so… I think that what took the most time was… To get all the details right, like… we were using the state at the wrong advance, then it's… it was a bit hard to, like, trace back where every balance source and state had to be say, at the precise location, plus make it efficient, make it work with the caches. Like, the design we went for was Maximum spec parity. At least visually and conceptually, and trying to hide the abstractions away. Sorry, like, the optimizations, abstract them away in the minimally invasive way possible. So I think you look at the code, it looks pretty much identical to the source, but it's still very performant, like… FCR runs in, like, 30 milliseconds.

On most slots. Unless there's, like, some weird, like, reversion or something.

Mikhail Kalinin: Great, congratulations. So, did you already, have it in the release?

Lion Dapplion: Not yet.

Mikhail Kalinin: Right, and yeah, I'll… There was, there was a kind of regression, or, whatever caused the reversal to finality a couple of weeks ago, so you have fixed that. Have you observed any reversions since that fix.

Lion Dapplion: Yeah, so we want to clarify this, higher ed metrics in the different loop points of execution of… the main FCR function. So, I think the, like, the metric Roberto Finality is misleading. Because that's not what's… so, the FCR was reverting to finality. Like, that condition was heating. But then immediately. restarting to justify, then re-verifying the root. So, from a POV of the user, there was no reversion. We want to add a new metric now that actually tracks if the confirmation route backtracks. Which, that's what I understand it, reversion, right? But yeah, the ones we reported, we fixed them, and the issue was that we were running state advance. With the wrong slot. So, Fortress State had advanced, but the FCR no, and that… Disagreement is what cost…

The reversions sometimes, if the boats were closed.

Mikhail Kalinin: Yeah, that's interesting. So, In terms of the metric, if you have a better idea of how to, actually better metrics, you know, yeah, please just don't hesitate to open the PR to EF To Beacon metrics,

Lion Dapplion: Actually, I haven't checked this one.

Mikhail Kalinin: agree, yeah.

Lion Dapplion: the standardized metrics at all, we just roll our own. Can you link them on the Telegram chat?

Mikhail Kalinin: Yeah, sure, I will do. But one thing to note here is that if you see a reversion to finality, you… It doesn't seem possible to, even if you're restarting from the most recent justified, at the same run. It doesn't seem possible to… You know, to confirm, to actually eventually, be at the confirmed block that was before, yeah, you got this version. So if you… if you can not, for instance, if you cannot reconfirm something. You will not be able to confirm it.

Lion Dapplion: Hmm, right.

Mikhail Kalinin: That's kind of it. So you will have… if you revert a finality, they will be backtracking, at least for one block, you know.

Lion Dapplion: So, something about the… in the main function. The last step only… can only run If the current confirmed route is… I don't remember if it's, like, one slot behind the current clock, Or in the current clock. Is that correct?

Mikhail Kalinin: the… Right, so the one… yeah, so if you run in the current slot, you can confirm the block from the previous one, at most.

Lion Dapplion: somewhere.

Mikhail Kalinin: asking.

Lion Dapplion: Yeah, something we are debugging now. Whenever we… whenever Lighthouse restarts. We cannot confirm the previously confirmed route.

Mikhail Kalinin: I mean, like, whenever it restarts after a reversion?

Lion Dapplion: No, no, like, if the… if the Beacon node stops. And then starts. The issue is that we don't persist all the state in FCR, we only persist the four-choice state, so we start FCR from the finalized. And then the algorithm is not able to reconfirm the same confirmed route that it had before. Shutting down.

Mikhail Kalinin: I see, yeah, but… So you do… you do restart for a short time. I mean, like, the downtime is small, right? Yeah, but it's not…

Lion Dapplion: Nice, because in the metrics, it looks like a reversion.

Mikhail Kalinin: Yeah, I see. I don't know if… I would expect that if you restarted a node, so you will… you will have to wait for… Or for the restart point, for the next starting point, which is… At least the next epoch boundary.

Lion Dapplion: Yeah, I mean, if we can fix that, that would be nice, because otherwise it looks quite ugly. So, okay, what I was asking is, in the function… Get latest confirm. At the very end, We only run find latestConfirmDescendant if the block epoch. is within one epoch of the Quran Epoch.

Mikhail Kalinin: Yep.

Lion Dapplion: Why is that?

Mikhail Kalinin: Yeah, that's… that's to… that basically is, is coming from From the safety. Groups. Otherwise, we will not be able to prove some. To actually see the evidence that confirming blocks is being safe.

Lion Dapplion: Right. So, what do we expect… So in the restart condition, The… because that route is quite old. the… We tripped the reversion to finalized. Because there's a condition… yeah, because the block epoch is pretty old, but then the restart to justified does not trigger for some reason, which I need to debug. Like, which of… which of these conditions is not…

Mikhail Kalinin: Yeah, I see.

Lion Dapplion: So…

Mikhail Kalinin: Yep.

Lion Dapplion: If we… so, question for you. If we persist the confirmed route, to disk. And then, when we boot Lighthouse, we start from the confirmed route instead of the finalized route. Is that unsafe?

Mikhail Kalinin: Yeah, it's a good question. It's… I believe that, in general case, it cannot be proofs that it is safe. That's how I would answer. I don't know, Roberto, if you have an opinion on that.

Roberto Saltini: Yeah, I mean, it wouldn't be safe under the assumption that we use. You could consider it safe. And the different synchrony assumptions. Assumption would be the synchrony, started… from Tweetbooks before you… denote, denote. shut down. So it wouldn't be safe according to the… yeah, to our assumptions. Does it make sense?

Lion Dapplion: Can you, can you repeat again?

Roberto Saltini: So, say that you… The node, you switch… you switch off your node. Two days ago, and then you start today. If you use what was confirmed two days ago, it means that it is safe only under the assumption that the network has been good. For two days.

Lion Dapplion: Right.

Roberto Saltini: Whereas the assumption that we have is that the network When you confirm something now. The only assumption we have is that network has been good for For 3 books, and they'll always be good in the future, but… We only assume that there's been good from two ebooks ago. Not from 2 days ago.

Lion Dapplion: Got it.

Mikhail Kalinin: So, actually, what happens, what's missed here is that after you restart, you start from the confirmed route, but you missed some events that happened in the network during the time of… during the downtime. And this, all this information is lagged. The algorithm actually lacks this information to, ensure that the block, you will, you know, you have, you had before the restart, before the shutdown of your node. It's… it's been safe, still, now. You know, so that's, I think…

Lion Dapplion: So, actually, conceptually, imagine… So… if you run an exchange or something, you would probably consume information from the EL, If you're running two processes, EL and CL, then the CL sends the forchoice update with the confirmed route to the EL. Then you stop the CL, the confirmed route is persisted in the EL. So, the confirm route is sticky in the EL, but it's not in the CL, which is strange.

Mikhail Kalinin: Yeah, I see.

Lion Dapplion: So in theory, like, if you persist the confirmed route in the CL, and then use it as a starting point, but then run the FCR once more before sending the FCU, that should be okay, right?

Mikhail Kalinin: Right, yeah, I see what you mean. Yeah, that's interesting. So EL will just basically keep it, it will not revert it back. Right. Okay.

Lion Dapplion: I mean, if the… it depends on how long the restart is. Like, if the restart is… 3 slots. I believe this would prevent the re- the… the rewards? But if it's longer, the condition… Getblockepoch plus 1 less than current epoch will trip, and then we will… Roberto finalize. And then we'll probably get stuck again.

Mikhail Kalinin: Yeah, I see. Yeah, I need to think about it.

Roberto Saltini: What is the reason for the… for restarting a node? Is that something that the dapper known? No.

Lion Dapplion: So, a version… could be a version update, could be a crash in the client, like an out-of-memory. Could be… I don't know, updating Linux?

Roberto Saltini: Okay. In this case.

Lion Dapplion: I'm changing configuration.

Roberto Saltini: You know? But then the ELD update the EL saying. Confirm block is now the finalized block, right? Buffalo.

Lion Dapplion: Could you repeat?

Roberto Saltini: After the EL starts, it would tell to the EL. And now the confirm block is the finalized block.

Lion Dapplion: Exactly.

Roberto Saltini: We'll say, until they see a… Doesn't restart the… the confirm block in the EL is thinking.

Lion Dapplion: Yes.

Roberto Saltini: Yes.

Lion Dapplion: And then from the EL point of view, it would look like a regression when there's no regression. It's an Clients are starting.

Mikhail Kalinin: So the client restarted, and basically, you see backtracking, or… and for some period of time, your confirmed block is still on EL side, then you see backtracking, likely. That's the concern. Yeah, I see. Yeah, that's, that's a good, good point.

Lion Dapplion: I mean, it's an edge case, but… Yep. You don't want to… Spook people, right?

Mikhail Kalinin: Yeah, right, that's something probably to think about. And, I don't know. I can't come up with a good solution to that.

Lion Dapplion: Yeah, let's, let's sync, pink async on this.

Mikhail Kalinin: Right, right. Yeah, thanks a lot for sharing all of that. Anything else you want to add on top?

Lion Dapplion: No, that's good.

Mikhail Kalinin: Great, and when do you expect…

Lion Dapplion: Sorry.

Mikhail Kalinin: Oh, sorry.

Lion Dapplion: I think you were talking that you had an optimization for empty slots. Is that… Released.

Mikhail Kalinin: For empty slots, yes, but for late blocks, We had a prototype for late blocks as well, it's not released. For empty slots, it is… it is in the algorithm.

Lion Dapplion: Okay.

Roberto Saltini: The, the, like, The difficulty for the late blocks is… We need to prove that that is correct using different proofs strategy. So that would be quite time-consuming. But at the moment, I think… The decision is not to do it. To focus on other things.

Lion Dapplion: Okay.

Roberto Saltini: Basically, not to implement this late block. Improvement.

Lion Dapplion: Because I wonder for… the users of FCR? This… the percentage we have now of 97% is good enough.

Mikhail Kalinin: Are you a question… are you asking that, or you're just…

Lion Dapplion: Yes.

Mikhail Kalinin: Stay tuned.

Lion Dapplion: I'm asking.

Mikhail Kalinin: Oh… I think it is, like, but yeah, maybe Julian can answer to that.

Julian Ma: Yeah, I would probably need to do a bit more digging, but I'd say probably yes. But yeah, I should do some more digging there.

Mikhail Kalinin: I have a question. When do you expect to release the, implementation?

Lion Dapplion: That… I mean, that will depend on the release. And I don't have approximations.

Mikhail Kalinin: Okay, so it will be in the next release, right?

Lion Dapplion: Yes.

Mikhail Kalinin: Awesome, awesome. That's great. And, yeah, let's just follow up and chat about this, point you raised, and also… If you have any, statistics on… any statistics on the reversions that you currently observe, that would be also great to see.

Lion Dapplion: you know, outside… The node restarting, we haven't seen anything. All done.

Mikhail Kalinin: Oh, that's awesome. Cool. Alright, any questions to Lion? Great. Thanks, Lion for… for that great update, and congrats on the, On the release, on the soon release. And we will move on to… to tackle.

Dmitrii Shmatko: Hi. We have implemented FCR in Teku. Currently, it's a branch, but we have already started to merge it into master, splitting into smaller parts and reviewing it one by one, but this could take a few weeks, at least two weeks, I guess. And we have, one issue, It's slow, it's about 150 to 100 milliseconds per slot on my net. But we did not focus on the speed, just the spec targeting. And I have compared, I took December 2025, minor incident, when we were, when we were switching to Fulo. And… had some loss of power. So I put around 40 EPACs in Tokyo and in Lighthouse to compare our confirming routes.

And it's, it's mostly, we get mostly the same numbers, but we have some diverge on On free epochs. But on every SLOADECU is more conservative, so it's… it's… It's acceptable. But anyway, I'm trying to decanter it, and I still have not found why we had… And as a Nimbus… And my current theory is that, that Harness itself, which calls the client. that it has some time out, or maybe something like this, and I am investigating in this direction. But it's definitely not a blocker, we started to merge it to the master. And, and we have added it with experimental plug, plaque, And after some testing, we will… we will definitely unhide it and start to advertise feature.

That's all.

Mikhail Kalinin: Great, thanks, Dmitrii. Thanks for the update. So, couple of questions. Do you pass, the spec test, and did you try to run it on mainnet?

Dmitrii Shmatko: Yeah, yeah, the password references, and, regarding my net, I have mentioned, it's, like, 150-200 milliseconds per slot. For calculation. Yeah.

Mikhail Kalinin: Have you seen any reversions on the mainnetron, or any other unusual behavior?

Dmitrii Shmatko: I… I have… I did not see it on normal mainnet, and I have just added metrics. I probably could see it on… if I replace some… some stormy period in my net. I will do it in the future, but currently not. I have just added this metrics, and I have a question regarding it. I have it in the chat. If we… if we have fallback in two consecutive slot… slots, is it… do we need to count it as two, or is it one fallback?

Mikhail Kalinin: Sorry, what count is 2, or 1 fullback?

Dmitrii Shmatko: For example, in SLOT, we have fallback to finalize. And in the next slide, we have the same. Do we need to count it as two events, or is it just one event?

Mikhail Kalinin: You mean, like, in the next slot, you're just not advanced, right? So, it's not like you have a… yeah. Oh, I think it's just one.

Dmitrii Shmatko: Okay… Okay.

Mikhail Kalinin: So, like, I would count the reversion itself, like, when you have to go… when you have to fall back to finalize. Even if, like, Finalized has updated after that. It's… yeah, it's still, like, the one accident of, you know, of reversion.

Dmitrii Shmatko: It will be more difficult to count metrics with such condition, but I will try to find a way.

Mikhail Kalinin: Yeah, I see. Okay. Any feedback to metrics is more than welcome, so just… yeah. We can… it's not, like, set in stone. It's just, like, a few metrics that are… Standardized, more or less, and that we would like to look at when we assess the performance of the fast Confirmation rule. Any feedback to that? That would be great. All right, so great, great to hear that you have started to work with the implementation, and good luck with, debugging and, you know, reviewing. Reviewing takes a lot of time. And by the way, what implementation you have used to compare yours? I mean, like, in terms of On, on that, on that tough mainnet period, after a full.

Dmitrii Shmatko: I have compared Vivis Lighthouse, But I'm not sure that it's… it is last Lighthouse implementation. I have started. from, from orchestrator, from Harness, from testing harness, and whatever version was there. I have used this… the one that Sam made.

Mikhail Kalinin: Oh, I see, I see. Yeah, maybe ask Sam about it. I mean, like…

Dmitrii Shmatko: It's… maybe it's salt, I'm not sure.

Mikhail Kalinin: I don't know. Yeah, you can also ask Lion about which one is… The most recent one. Alright, great. Anything else, Dmitri, to share, or any questions to Dmitri? Cool, then over to Lodestar.

Nazar Hussain: Hi, can you guys hear me?

Mikhail Kalinin: Yes.

Nazar Hussain: Smoke. I'm sorry if I was, like, driving right now, so my connection is very bad at the moment. But anyhow, there you go. We did a recent performance improvement in FCR implementation. Related surveillance calculation. And, the last incident which I shared earlier was That we seek to reverse our research. Because, Node was taking too much time at the info concrete. After this performance regression, like, improvement, I haven't seen that thing again. on our node, which I'm testing. But we will keep observing this thing, and during… last week, I was working on one scenario where a node… Start with the range sync. And during this ranging process, the FCR reset a lot of times.

Which is fine, we know, because the node is same thing, but from the metrics perspective, it was looking very ugly, so I'm working on an implementation with We will disable the FCR during the syncing, and once the node is synced, then we will enable it back, so that we get the stable matrix out of it. This PR is, like, under review. Hopefully, we will get technology energies in the upcoming RPCs.

Mikhail Kalinin: Awesome, thanks, Nazar. Yeah, that sounds good, and especially that there are no reversions after the fix. I think it makes sense to disable FCR for… for the time, the notice being during the, And it's been done with, like, the arrange sync. And, yeah, thanks a lot.

Nazar Hussain: Thanks a lot.

Mikhail Kalinin: for… yeah, sir.

Nazar Hussain: We had this earlier, like, implementation where, we subscribed to the gossips, a subnet on a particular behavior, where we have, node is syncing, and there's one epoch, delay there, so I use the same logic. To implement the FCR, like, to disable the FCR as well. So, once the gossip topics are disabled. We are not receiving any traffic, so there's no need for FCR to be already computing. So, once the gossip topics are enabled, no async, then the FCR will trigger again.

Mikhail Kalinin: Yeah, sounds reasonable. I'm just curious if other clients handle it differently, I mean, the wrench thing. Do… do you disable FCR, or… yeah.

Nazar Hussain: You asked this question to me?

Mikhail Kalinin: No, no, I'm just, like, to all other clients, what's, what's the, behavior around the, during this, the range thing? Is FCR disabled, or not? Alright, I take it as… yeah. Sorry, Boma. Could you repeat, please?

Mercy Boma Naps-Nkari: On our end, it's not the same for January.

Mikhail Kalinin: I see. So it might be the case that you also, Could face with some reversions during the, range sync. So it probably makes sense to disable it.

Mercy Boma Naps-Nkari: Yeah, that's something I need to look into, because I'm not, like, donate. I have some consultant. Sipper.

Mikhail Kalinin: Okay. Alright. And, Boma, do you want to provide any other update, other than you have posted in the chat, or asked any questions? On the implementation side.

Mercy Boma Naps-Nkari: No, no, thank you. Nothing for now.

Mikhail Kalinin: Alright, yeah, hope that it will be reviewed soon, and merged as well. Yeah, then let's move over to Prysm. Jun, do you want to… Yeah, I, I see still, like. As you said in the chat, it's still under review. And, yeah.

Jun Song: Yep, so I guess this is his first time speaking in FCR call, so, nice to meet you, everyone. And, Terrence wrote most of the PR, and I'm currently reviewing, Terence's works, and it looks fine, mathematically, but I've found there can be some improvements in terms of performance, so… We are still, reviewing that works each other, and hopefully it will, get merged soon, but, I don't have any due date or a conviction about, the merging date. Yeah, so that's… that's the update.

Mikhail Kalinin: Great, thank you so much. Did you… did you try to run it on mainnet already?

Jun Song: from my side, no, but I should ask Terrence, and I can also, suggest, running, FCR in our Prysm cluster.

Mikhail Kalinin: Yeah, looking forward to the results of those runs. Yeah, thanks a lot for the update, and nice to meet you.

Jun Song: Just one quick question. So, I, as far as I know, there's a FCR simulator, developed by Sam in its Panda Ops. So, is there any room to, run those simulators at this moment?

Mikhail Kalinin: You mean, like, any room for, in… any resources in ETBA and the ops team to run them again?

Jun Song: Yes, yes. Because, yeah.

Mikhail Kalinin: Yeah, I see what you mean, and I guess you want to run it with Prysm as well. I don't know if it's… if it's in the simulator. I mean, if it's integrated into it.

Jun Song: Yeah, so Prysm, as for, at this moment, it is not integrated in the simulators. So, I think, the integration can be started, because we have a branch, passing this backtest. So, apart from running on mainnet, it will be very helpful to see, the metrics or status, on the past, data.

Mikhail Kalinin: Yeah, I see. So, I… Yeah, I don't think anyone from ETH bundles is on this call, so I will just… yeah, let's… let's ask, ask those guys if they can do this. I mean, like, they probably will not, run this stuff, but probably integrating Prysm is one of the… one of the important things that we will need to do anyway, I mean, for… for this simulation. So… Probably, it could be that… If they have, spare cycles to integrate Prysm, and then you can run it and test your implementation. on… on some mainnet data. Does it sound good to you? Alright, cool. Let's follow up on that. Nice, thanks a lot, thanks again for the update. Yeah, that's great.

Is it all for client updates today? Yeah, we spent a decent amount of time on this call for client updates, which is awesome, and I believe that all Minute clients are Had to… Great progress on… implementing the Fast Confirmation Rule, which is awesome. Congratulations to everyone. And now we will move over to… Spec and testing updates. So, there is just one PR to share. It is. first, it does two things. There is a small edge case test, which basically… For the case, for this scenario where, the total active balance will be affected by…

If the total active balance is not used from the balance source, so that the confirmation will not… Will not pass, so this highlights this case, this edge case. And, also this, PR has a… Safe execution block hash. As a property, it adds this, property to the list of the checks, of the FCR checks. And, yeah, this property is important for… yeah, before Gloas, we should… Like, have, Safe execution block hash corresponding to the most recent confirmed block. Confirm BeaconBlock, but after, since Gloas, and after Gloas and the next cut works, it will be, at most, the, parent's execution payload. And, this property, is kind of, like, the main purpose of

Having this property is to test this transition from from before Gloas to Gloss. That's… yeah, once these were merged, we can get tests, with that. So, just be a heads up on adding a new property there. That's on a new check that you might want to add to your test runners. And, I don't know if anyone wants to provide anything, any, any, results from… I know that Barnabas were… was running, some of the implementations of… on the Glamsterdam… Amsterdam DevNet. any… Anything, any updates on that?

Alright, so, yeah, we'll follow up around us, after the call. Lion Post-glas Confirmation time doubles to two slots, right? So it's kind of like… Right… Yeah, probably need to take a look at Fast Confirm 8, Yeah, yeah, yeah, good. Yeah, that's, that's great, there is a fast confirmed. Badge in DORA. Which is nice. Really. And I believe there were some clients that, pointed out to… and incorrect. save block hash, in… in class, but I don't know, I don't know the statuses of… the status of that. Alright, yeah, the next, next thing… Anything on the spec-end testing?

Okay, I don't know if there are any API or metrics updates, so we can skip this. And move to the research updates.

Roberto Saltini: Yeah, the… Same thing. Main update is the one that I posted on the… Telegram group that we… Last week, we released the updated paper that includes a definition basically present the algorithm in that paper, closely matches the one that is in the implementation. Also, we I've improved the presentation, we start with an intuition, try to You know, without… and basically removed all the super formal proofs to the appendix, and the idea is to… to provide a gentle… semi-genter introduction at the beginning, and then if one wants to… Yeah, to really check that everything is right, one can look at the proofs at the end in the appendix. The main update, yeah. And then, in the telegram group, Francesco, Francisco shared,

it'll improve that, I think was understand… I understand mainly. Yeah, LLM generated. just, you know, one or need, really, to check that the model that the formalization of the model and the properties are correct. So, I mean, it's… it's good to see that That can be done. I just want to caution people that yeah, before. You know, for being able to say that we have a formal verification of the protocol. We really need to check the link formalization. Of the assumptions, and the… The overall environment and the protocol is… is correct. That's it. Don't know if there are questions.

Mikhail Kalinin: Awesome, thanks, Roberto. Congrats on the… publishing the paper, and yeah, to you and to everyone who has contributed to the paper. That's great.

Roberto Saltini: Which you go to?

Mikhail Kalinin: Nice. So… Yep. If there are no questions to Roberto? I have one thing I forgot to raise during the testing, item, action item, sorry, testing update. One topic that, Lion has, raised recently is basically about, fasting the fast Confirmation Rule implementation. Lion, do you want to expand on these, or… Do you think it makes sense to have a separate call dedicated to discussion of that fasting efforts?

Lion Dapplion: One second, let me change mics. Okay. So we haven't done an exploration, to be honest. It's just… it's just something that should be possible to do, and we should do, now that we have implementations. But that's as far as we got. So we need to figure out the best setup.

Mikhail Kalinin: Okay, do you want to use, do you want to… utilize some tooling that is used for… by the Big and Fast project. Or do you want to build something from scratch?

Lion Dapplion: Honest answer, I don't know, because I didn't work on the original BeaconFuzz implementation, so I'm not familiar with the details.

Mikhail Kalinin: Alright, I see. But yeah, yeah.

Lion Dapplion: I just posted the message to deduplicate efforts, in case you guys were already looking into that, and just to signal interest.

Mikhail Kalinin: Yeah, see, in general, I think it's, it's a good idea. It would be great to have, to have these, but, yeah, as far as I'm concerned, nobody is currently working on it. So if anyone is interested, just rise your interest in the chat about, you know, fuzzing the false confirmation rule. I believe that it would be possible to have a fasting against the spec, but the problem with the spec is that the spec is quite slow. And, maybe because of that fasting. Differential fuzzing between pairs of implementation makes sense. As well.

Lion Dapplion: Yep.

Mikhail Kalinin: Alright, cool. And yeah, before we wrap up, anything else? You wanna discuss today?

Lion Dapplion: So, I wanted to mention, I asked in the chat, why… The safe hash is set to justify it. Because one… one oddity… So, as I mentioned, Lighthouse has this rule. Where, if the head is lagging too far behind, we will stop computing FCR. And then the effect would be that the save hash that we sent to FCU would default back to justified. But the kind of… quote-unquote default of FCR is finalized. So, from the point of view of the user, if the network stalls, or the node stalls, it could see… A reversion of head into finalized, then into justified, then back to finalized, then back to head. Which is weird. So, at least conceptually, it would make sense.

To move… the off. Status. Of this hash into… The finalized, so that we don't… you don't have to, like, flickering between finalized and justified, depending of… depending… On the fast Confirmation rule being on or not.

Mikhail Kalinin: Yeah, I see. Yeah, I… I understand that. So, and I think it would be reasonable. Except for, yeah, I have just one… one concern here, is that… Somebody, we still don't know, but we've been asking this for several times, and got to know, No confirmation and no response from anyone who used Safe Block before. like, until now, as… as a… a tag for, you know, for… to query justified block hash. So we basically… Cannot be 100% sure that it's not used to query for a justified block. But, Yeah, I think, yeah, what you're suggesting is reasonable, so we either have a finalized block hash, or we have something that is closer to the head is given by the pass Confirmation rule, and there is no, other stuff, there is no other, semantics for the safe block hash.

Lion Dapplion: Right.

Mikhail Kalinin: Right. I don't know if… yeah, what do other things on that?

Lion Dapplion: No, that's it.

Mikhail Kalinin: Okay, are there any opinions on whether we should revert to finalized by default, if not enable the FCR? Alright, maybe we can follow up on this, after the call. Cool, nice. And, yeah, before we wrap up, one more thing. I think, like, the next, the next call will be, The last one, let's… Let's take it as a default, and decide on the next call, after 2 weeks from now, if we need to continue these breakout calls. Cool. Alright. Thanks, everyone, for coming. Thanks a lot for the great updates, and for a fruitful conversation.

And see you in a couple of weeks. Bye-bye.

Dmitrii Shmatko: Kind of care by.

Roberto Saltini: Thank you, bud.

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