Fast Confirmation Rule Breakout #12

Transcript

Mikhail Kalinin: Hi, Roberto. Hello, Dmitrii.

Dmitrii Shmatko: Hello, Mikhail. Hello, Roberto.

Mikhail Kalinin: So, as usual, we'll wait for, I don't know, maybe 4 to 5 minutes. For more people to come. Morning, Justin.

Justin Traglia: Good morning.

Mikhail Kalinin: Hi, everyone. We'll wait for… Or more minutes. To let people come.

Alright, let's go ahead and get started. Everyone, welcome to the bus Confirmation Rule. Breakout number 12. And, here is the agenda. Yeah, before we start, I would like to say that this is going to be the last recurring Breakout for fast Confirmation. stuff, so… Yeah, and, we have a… Several items on the agenda to cover today. I believe that if there will be a demand on Any breakout session in the future, we can organize some ad hoc call. But… As long as I can see, we made a great progress so far. And, yeah, this call might be already not that important. To have it, like, on a recurring basis. Okay, so…

And yeah, today we'll start with, as usual, with client updates. So… Let's start from Grandine.

Mercy Boma Naps-Nkari: Hello, good afternoon. So, the oldest on Ireland is… I updated the test cases, and we only have, like, 3 tests filling, which is… part of the spec issue that was opened. So, once we get, the particular version, the release, it should pass in our own end, so… but… the PR is ready, and then I'm also hoping for PVAS to review, because he was… reviewing the PR, for… I was asked to take, switch the branches to Glamsterdam. That's all.

Mikhail Kalinin: Great, yeah, great. Yeah, there are issues with the tests, we'll cover this today. I believe that all the PRs emerge now. So… So you should pass the test with the new test vectors. I hope. I have a question, did you… Did you run your implementation on the mainnet? You try…

Mercy Boma Naps-Nkari: No, no, just, LeCore.net.

Mikhail Kalinin: Okay. Yeah, just, you know, curious about the main app. Boom. Okay, cool. Because, there was, there were some issues with other client implementations in the past, so I think, like, mainnet is a kind of, like, smoke test. For… for… Or FCR. Alright. Thanks for… thanks a lot for the update, and let's move to… Lodestar.

Nazar Hussain: So, last… We've, like, a lot. After our last breakout call, I… was working on some of our integration, like, a spec test, and I found some small, minor details that I opened the PR. thank Mikhail for their review, and those BRs are merged. Yeah, now I will dig further, once that… those PR are released, and I will, Update our spec test, and then try to cover up And these were identified during when I was working, enabling Tuggle OS. Spec test for the fast Confirmation? So hope after these are released, then all the Gloas stuff will be working right for us.

Mikhail Kalinin: Nice. But you already have a release, right? So it works fine on the mainnet, it works correctly, right?

Nazar Hussain: Yeah, yeah, it's worked fine. These are just, like, few spec tests, and I digged further, and it was just the issue with the vectors, not with the implementation. So, I have a few spec tests disabled in our CI for now. The implementation is working fine, but once these, lay tests release is done for the spec test, and I will update our CI as well, to have run all the spec tests for Boscom Commission.

Mikhail Kalinin: Right, and yeah, and this Gloas update is, like, basically a Gloas thing, right? So, we are fine with that.

Nazar Hussain: Great. We are good with it.

Mikhail Kalinin: Yep, thanks a lot, Nazar.

Nazar Hussain: Thank you.

Mikhail Kalinin: Next. Next reason.

Jun Song: Yep, so I can give a short update from Prysm. So, we don't have a lot of things to update, but, I confirmed that, we at the FCR branch. is passing the latest or a nightly spec test that, we, that the Consensus specs are serving. So, during that, I found a couple of test generation bugs, and with, those fixes, I, confirmed that, our implementation passes the spec test, and we didn't have, run, those FCR features in mainnet or DevNet so far. I think, we need a couple of more, deep review for our implementation, even though we passed this old backtests. So, that's all.

Mikhail Kalinin: Makes sense. Thanks a lot, and thanks for the PRs to fix, those couple of tests. Yeah, they also merged. Just… maybe today. Alright, cool. And, Teku.

Dmitrii Shmatko: Yeah, we continue to merge, feature FCR branch to the master. You know, smaller chunks. It will take another 2 weeks or three, we are in the middle, pound a few bucks while merging it in smaller parts. And, that's all.

Mikhail Kalinin: Cool, did you manage to find the reason, behind the comparison failure with Lighthouse?

Dmitrii Shmatko: Yeah, not yet. I will recheck it today, because I, I had… We have added a few fixes which could change behavior like this. Maybe it's already fixed, I will run it today.

Mikhail Kalinin: Okay, nice. How much time… Does it take for you to run these comparison tests?

Dmitrii Shmatko: Like, 50 minutes or something like this.

Mikhail Kalinin: Okay Yeah, that's… that's good, I think. By the way, while we are here, like, I have a question to… to… Jun may be. Have you tried this, tool from EthPandaOps? to compare your implementation to maybe Lighthouse or Lodestar.

Jun Song: You mean the FCR simulator?

Mikhail Kalinin: Yeah, yeah, yeah, this one.

Jun Song: Not yet.

Mikhail Kalinin: Okay. Yeah, I was just, you know, asking, because, yeah, it was an interest from your side, last time, last call. Okay, cool. All right, thanks a lot for the updates. Before we move on to the next… Any… anything else, by the way? Any other updates here from the client's implementation side? Okay, cool. We'll move on to the next one. Autos, welcome to the FCR call. This is here. Okay. So, the next is, Glamster Dam DevNet Testing. This is the report by EthPandaOps.

Which is… Which is great. I believe you have already seen this, just wanted to share here. And Barnabas, if you want to add anything on top of that. Please feel free to.

Barnabas Busa: Well, we are just waiting for the implementation from President Takubmin. I would say.

Mikhail Kalinin: Great, these, DevNets tests, Was, were very helpful. To find some issues with, like, specific laws, Clause, behavior around fast confirmations. Alright. Let's move on to the next one. So the next one would be the client comparison on historical data. We were planning to have, to use the FCR simulator, and, once we have all implementations. Once we have all clients, Equipped with the production-grade implementation of fast Confirmation Rule. We were discussing that it will make sense to… To basically run the, this simulator, these simulations again, and compare, do the comparison tests. Of different implementations. I believe it's still a thing.

So, but I think that we should wait for, for, basically, for Prysm and Teku. To… to… to basically add them to… to these… To this harness. And, we'll just follow up. on that. Asynchronously. Once, once, yeah, once the prison deck already, I'll just basically ask if Panda opts to do these simulations again. And see what it gives to us. Right. I just wanted to mention that this is still a PIN. The next is backend tests. So… There are… Yeah, there is a… there are a bunch of PRs here. you can find them in the agenda. This PR is basically… has been merged, so this should cover the Gloas issue as well, where the safe execution block hash is

Mistakenly passed. from the current… From the most recent confirmed block, but not from its parent. So one of the… this was one of the main goals of having this PR. And, the rest, PRs are basically fixes to… To… to the fast confirmation test, and, to… the tests with the disabled BLS in general. Thanks, guys, for submitting those PRs. That was… Yeah, pretty useful. Okay. Any questions on the tests and the spec? I'll just post the R's to the chat.

Cool. The next item is fuzz… fuzzing client and limitations. On the previous call, that Lion basically raised this topic. to… Understand if there is an interest in FOSIN implementations? Which is actually… We decided to basically think about it. Or till the today's call. So, any thoughts on that? Except for that it would be quite useful, but… How much do… do you guys think this is important? For your implementations.

Justin Traglia: Alternative… alternatively, I was thinking that we could ask the security team to spin up their, agent swarm. On the FCR implementations? I mean, it's not fuzzing, but it's…

Mikhail Kalinin: Yep.

Justin Traglia: Like, agent buzzing, in a way. If that's something you're interested in, we can ping them.

Mikhail Kalinin: Alright, cool. Being Justin. about agents, agents,

Justin Traglia: Yeah, you should… Yeah, you should reach out to Nikos from the security team.

Mikhail Kalinin: Thanks, Justin. As for me, fuzzing would be a really important thing. But, it depends on… On, basically, the capacity. and bandwidths. Of the team that will handle this. So, I, yeah, I see a lot of, you know. Yeah, I can say that that would be important, but yeah, that's just my opinion here. Because even though we have a good test coverage, some edge cases might still be there. That are not covered with the destined suit, best suit. Which could be found in fuzzing. And, basically. client comparison on mainnet historical data. This is kind of like… it's not fuzz, it's not differential fuzzing, but it's some kind of, like, test that will basically compare, and we'll try to

We'll attempt to highlight some. Anomalies and behavior… different behaviors in clients, and potentially identify some bugs. So… Alright, if anything, if any thoughts on the fuzzin, please just post in the Telegram group. We can discuss it there. Alright, well, let's… Move on to… to the next item. On the previous call, on the last call, we have been discussing the, save block hash. Set to finalized instead of justified, when the bus Confirmation is disabled. So, any thoughts on that? Should we make this into the spec?

So for the context, the reason to do this is basically, so we have a fast confirmation, which falls back to finality. And if the fast Confirmation is enabled, it's, it's, it will… Yeah, the save block hash will point out to either to finalized block or to the block that is Basically, yield by the fast Confirmation rule. There are just, you know, two things here. But EFAS Confirmation is disabled, and In this case, it will be… saved block hash will be basically a justified block hash. And the justified block hash. It's… its safety is questionable. So, that's the RTML for making this change. Any thoughts would be… Really appreciated on that.

Roberto Saltini: Just wonder whether… There aren't any users that… It's safe to mean justify, so rely on the fact that this… Most of the time, it's just one e-book behind, rather than two. I mean, I cannot… I wonder if there are some weird scenarios… there is some weird scenario where… -Oh. Using finalized instead. Bright things, just because of the extra e-book. Not sure. But they, you know… Not, not, not, not applying these changes, also. Not great, because of… yeah. because of the difference, so I… I didn't have a good answer. I don't know if anyone… Didn't see any… an issue.

Mikhail Kalinin: Yeah, I… I actually… a bit helpful in making this change, whether it makes sense, and also. Yeah, because… We don't know, basically, justified block hashes. used by anyone. I mean, like, safe block hash is used to derive the justified block hash. This is kind of still a bit of an open question here. So probably it makes sense to… Do these change? A little bit later, or… When the, pass Confirmation… when we get more, understanding of Whether this is the case, if anyone uses a block hash to get the justified block hash. If any thoughts on that, please, yeah. Potuz, you mean you don't send justified, but you send unrealized justified, right?

Potuz: Yep.

Mikhail Kalinin: Yeah. Yeah, it's still, like, more fresh, more recent, block than the, finalized block. Yeah, the safety…

Potuz: Safety assumption of unrealized justified is the same as of justified. And a client will not reorg either of them, if there is… Synchrony.

Mikhail Kalinin: Right.

Roberto Saltini: That…

Mikhail Kalinin: That's true.

Roberto Saltini: That's true, only if… analyze, justified is from the previous e-book, and they are not to… To towards the end of the e-book. Bye.

Potuz: No, but the safety assumption is the same. If… if you are… the only way to reorg either of them is on a period of asynchrony. So, if there's no safety… there's no safety benefit into using justified versus unrealized justified. It's true that finalized has a bigger safety assumption. Well, has a less…

Roberto Saltini: I agree, I agree there is no… I agree that there is no difference between… Analyze, justified, and justified, yes. That's true. Yeah, what I was saying, that if the rely is justified, all justified is from, let's say. Three epochs ago, it's not really safe. Because there could be some hidden… Conflicting checkpoint from the previous epoch, for example. That showed up during a synchrony, now… now we are under synchrony. That is, like, almost justifies a point. Formed in the past. During a period of asynchrony? Yeah, so that's what I was saying, but I do agree that If you're okay with justified, we're also okay with our lies justified.

Mikhail Kalinin: Aye? thing that… By default, I would not make this change for the reason that if there are users of a saved block hash. That, and they should be aware of the fast Confirmation rule. And they should actually, run their nodes with the feature flag that enables fast Confirmation rule, so… I… Don't… I think it's gonna be a problem, for… for them, you know, if we don't do this change. Oh, right.

Roberto Saltini: What about, though, like, RPC users that connect to RPC providers. You know, they might not be in control of which flag has been used.

Mikhail Kalinin: Yeah, that's… a good point, but I hope that RPC providers We'll make this right, the thing right, so if they serve save block hash. It also should be coming from the fast Confirmation Rule. What do you think?

Roberto Saltini: Yeah, not sure, but, you know… Seems that, you know. Any decision has its own drawback, so I have to say which one is.

Mikhail Kalinin: Yeah, I just see that the fast Confirmation rule deprecates the previous approach to, you know, to… to actually serve in these, save-Blockache stuff. Yeah, potuz?

Potuz: So there's one… one situation in which, it might be different to serve the fast Confirmation rule than justified or finalized, and it's just that the surface for client bugs is much higher. And… and the time to catch them, it's much shorter. So it's… the change to give either justified is just stateful, and you have it in the state. And if there's a bug, then the whole client is already in a consensus bug. So, it's pretty safe to be sure that if your RPC provider is giving you the justified checkpoint, it is actually justified. If it's giving you the unrealized justified checkpoint, there's… there might be a bug, but still, again, those paths are very short, are very small. So it's unlikely to have a bug.

But, I mean, this fast Confirmation rule, it's been tested, it's a very large change, it changes… it requires a full new fork choice implementation. I'm not sure if I am a large, like, roll-up, relying on this for deposits. I'm not sure if I want to switch quickly to fast Confirmation versus using justify for a while.

Mikhail Kalinin: Right, I see, that's a fair point. But we've been trying to get the understanding around whether anyone is using justified BlockHash.

Potuz: Oh. I can give you one data point. Perhaps they moved back to finalized, but at least for a few months, Arbitrum was using SAFE, for deposits.

Mikhail Kalinin: Yeah, yeah, I can recall that. That was on… after one of the calls where we were trying to To actually, yeah, facilitate this discussion around the usage of safe block hash. Before… before we introduce fast Confirmation. And Arbitrum basically was saying that, They're gonna be fine with switching to… with switching to finalize, but yeah, I don't know. Whether it has happened or not. But I believe that Arbitrum, Runs their own nodes, right, to, gets… disinformation.

Potuz: Oh, yeah, yeah, so I doubt there's an RPC provider of this. I'm sorry, an RPC user of this.

Mikhail Kalinin: Yep. So, actually, if you… if you run… if you run a client which, there is only one client, as far as I am concerned, that enabled this feature by default, which is Nimbus. Other clients have a feature flag. So if you run a client with a picture flag, Must be that. Clearly understand what the implications are. So I think, yeah, from that perspective, it's still kind of looking fine. Alright, thanks a lot for… discussion around this, and yeah, if anything, please just, you know, drop it in the Telegram group. We can discuss it there asynchronously. Yeah, the next item is kind of related to safe block hash as well.

There was a… There was a… Kind of… not an edge case, but the case that Deplian mentioned. On the previous call as well. So what should we serve as a safe block hash when CL node is down? And, right, or just recently started up. So, in this situation, save block hash. will be… Capture it by the execution layer client. And, until the EL node, starts up, and, Catches up with the head and restarts the first confirmation chain. So these save-block hash will be kind of stale on the EL side. But, We should also consider the fact that It does not make this safe block. unsafe, I mean, like, this situation.

So under… if the assumptions that we are making on the synchrony and adversarial power, kept The safe block will still remain safe, so it will not be locked out. So I think that, yeah, that's a good point to think on what could be done here, but I don't know. I would say that, I think using saved BlockHash is still Good enough in this case. Roberto, maybe you have other opinion on that.

Roberto Saltini: I mean, you said that using safe-procache is fine in this case? You mean until the… until we catch up? Until the CA catches up?

Mikhail Kalinin: Yes.

Roberto Saltini: And what would be… what would the alternative be, though, like that?

Mikhail Kalinin: The alternative is basically, yeah, once EL node is down, it doesn't seem like EL will understand that it's down, and, will do some fallback. We'll do any fallback. So before… before they restart, before the actual startups of a CL node, EL cannot do much here. But when the CL node is start up. By default, it will reset. It depends on the implementation, I believe. But by default, it will reset the saved block hash to the finalized block hash. So, after a short restart, when, say, the upgrade of a CL node is happening. After a restart, after this upgrade is done. There probably will be a reset from saved Bot Cash to finalized Bot Cash, which might be…

a bit behind, you know, I mean, the finalizable cache, so it's resetting the save block back. In time.

Roberto Saltini: Hmm.

Mikhail Kalinin: So if client… yeah, if client implementations, I don't know how much time it usually takes to upgrade your node. Or, you know… If it takes, like, more than 2 epochs, then it's probably fine. In most of the cases, finalized block will be advanced. If not, then we have other problems in the network. So, it's fine to fall back to finalized in this case. But yeah, if it takes less than two epochs, then we will see resets, too. A blog that is older. And yeah, that could be, should lead to bad UX.

Roberto Saltini: Hmm.

Mikhail Kalinin: Potuz?

Potuz: There's more nuance than just the two epochs. So there are several ways in which node operators restart a CL client. So if you keep your GB and you restart, you… so the client might start from the previous head. And clients, like… there are some clients, like Lighthouse, for example, that would download… and I think Teku does the same, Dmitrii can tell me otherwise. But I think they download the full fork choice to disk. And then, they pick it up, and they pick it up from head. So in that case, the fast block will be stale on the… on the CL, but they could just give the same. Some other clients, like Prism, would just fall back to the last finalized checkpoint that they saved.

And that will be a reversal, regardless if the finalized checkpoint has advanced on mainnet. And then if you do a checkpoint sync, then of course, if you do a checkpoint sync with the latest finalized, then it would be what you just said. But I think it's hard to cover all cases. Perhaps the simplest would be for the for the EL to recognize that it's falling back to a previous safe head.

Mikhail Kalinin: But how would the EL recognize this? Or you mean, like, to recognize this and ignore?

Potuz: Right, it's going to be… it's going to… the CL will start… in one of these scenarios, the CL will start and send back the previous finalized hash.

Mikhail Kalinin: Yeah. Yeah, I see. Yeah, thanks for sharing this. So at least it's gonna be implementation dependent, or we do something with EL, which is… Kind of… Like… Kind of difficult, you know, to… It's gonna be a hard sell, I believe. Okay. So, but, Roberto, what do you think if client implementation Keeps the, save block hash. Oh, sorry, yeah, so, sorry, confirmed route, if it caches the confirmed route. From before they restart. Do you think this is, like, a safe behavior? Yeah, and use this confirmed route after the restart.

Roberto Saltini: But, like, it… mmm… depends how long it takes to restart. Like, because the synchron assumption on that, whatever is confirmed is the synchron started No later than France. Three books ago? So, you know, if we confirm the block 5 epochs ago, now our assumption is that Synchrony started 7 epochs ago. But wait, but…

Potuz: But the confirm block cannot roll back, right? Even if we lose synchrony, We wouldn't roll back that confirmed block. Yeah, we'll fail.

Roberto Saltini: No, we… There are conditions under which we… Go back to… to… Personalized, because we cannot trust that that block is safe anymore. At the moment. Like, if your block is older than 3 books, then we revert to formalized, for example. If the confirmed block is older than 3 books.

Mikhail Kalinin: Right.

Roberto Saltini: lost.

Mikhail Kalinin: Yeah, it's just in the algorithm. Yeah, I see. Okay.

Roberto Saltini: I don't know, it is a tricky one, like, it's a very… It's also very hard to specify, because it's about the interaction between EL and… Yeah, post. Yeah. I mean, in most of the cases, we'll be fine. Because, actually, you have synchrony. We rarely ever asynchronous, so… In practice, I think. Is that a big issue?

Mikhail Kalinin: Yeah, then if we want to, actually have this behavior, that the, confirmed route is cached. Then we will have to… Then the implementations will have to… wait for… Do not run the fast Confirmation rule. Before the start… the new starting point, right? Otherwise, algorithmically, it just will roll back to the finalized block hash. In most of the cases. Because the saved block hash will stale and be older than two e-books. So it's like, yeah, as you said, it's gonna be, like, tweaking the algorithm. Or tweaking the implementation.

Roberto Saltini: Yeah, let me see…

Potuz: Wouldn't it be an automatic rollback if the EL takes care of this? I mean, the EL can know when the fast confirm block is older than two epochs. So they could just roll back to finalize. They do have the finalized checkpoint already cached. So they can do this rollback themselves.

Mikhail Kalinin: Yes, but currently it's in the algorithm anyway, so CL will do this.

Potuz: Yeah, I understand, but the point is that if the CL is down, the EL can have only this little piece of this algorithm. If the EL is down, the EL can serve the stale one up to two epochs, and then suddenly realize, oh no, I need to fall back to finalized.

Mikhail Kalinin: Yeah, I see. But it's not gonna serve the problem of, you know, resetting the save block hash.

Potuz: Yeah, it will, because when you restart, when you restart the node, if you restart the node with your head, and you restart it, like, over two epochs from now, then the EL already took care of, like, falling back to finalized.

Mikhail Kalinin: Right, but I believe the original issue that we tried to think about here is the UX issue, when you basically restarted a node and your save block hash was reset back in time. If EL does this, then effectively this will…

Potuz: No, the EL will not. If you just restart your node immediately, then the EL will not fall back to finalize, because two epochs haven't passed.

Mikhail Kalinin: Okay. Yeah. Alright, I see what you mean.

Roberto Saltini: Because it's an issue that… If we restart the CL, the CL will roll back to finalized regardless, because that's what we do when we start. But none of the nonsense.

Potuz: really, like, Lighthouse would just keep the head.

Mikhail Kalinin: Right, but if they restart took less time than two epochs, then this reset will not happen. Only as well. And if EL keeps the confirmed route cached and starts with this confirmed route, it will be still served to the EL.

Potuz: And that's a good one, right? If two epochs haven't passed, then this one is still confirmed.

Roberto Saltini: Yeah. Yep.

Mikhail Kalinin: Alright.

Roberto Saltini: Yeah, yeah, so, but this is not how it is specified, it is implemented now, right? We're not caching at all.

Mikhail Kalinin: I… don't know, maybe? developers can ask… answer to this question. Do you cache the confirmed route, or do you, restart every time? the Confirmation rule.

Potuz: I haven't looked at Terrence's code, but I'm pretty sure we're gonna restart it, because we don't… we don't restart from head.

Mikhail Kalinin: Yeah, yeah, yeah.

Potuz: We don't download our fork choice to… to… We don't upload our forges to the database.

Mikhail Kalinin: Yeah, I see. Okay, so…

Potuz: Lighthouse made, because Lighthouse actually saves the full fork choice, so… I don't know what they do on the first Confirmation, but they… when they start up, they… they do pick their latest saved fork choice.

Mikhail Kalinin: Right, I see. Okay, so… It seems safe to use the confirmed route that is cached, and that is not… Older than 2 epochs ago? If it will be older than 2 epochs ago, then the algorithm will reset it to finalized block. This is something that, to keep in mind for the users of the FCR, then. And, yeah, implementations may actually cache the confirmed route. This is, like, three things that I can conclude from our discussion today. Please correct me if I'm wrong. Yeah, also, this behavior… the cache in confirmed route is going to be implementation dependent. This is the… the other thing. Because not all clients, basically, dump their fork choice state… fork choice store to… to disk.

ELS, EL can also fall back, but this is gonna be the EL change, which… I would try to avoid, if possible. Alright. The next one is fast Confirmation Post Clause. So, what we have been discussing recently as well is that, In Gloas, we cannot confirm the… The block from the previous slot, as we do before those. This is because of the new… slot structure. So the DAS confirmed block will be from 2 slots ago. And, we were also… considering… Doing some… improvement to the algorithm using PTC votes in order to Consumed the, A more fresh payload, which is, yeah, the payload from the previous slot.

As… to actually provide, to actually support the same behavior as before Gloas. And, yeah. but there are complexities, and this is a change to the algorithm. so, it doesn't seem like an easy thing to do. Potuz?

Potuz: I guess Roberto is here, but I don't believe you guys can use PTC for anything like this. Ptc will not attest for validity, so… I would be very skeptical that PTC would allow you to To… to say something about the previous one.

Mikhail Kalinin: Right, but if you have validity, if you have a local validity…

Potuz: You will have validity already of the previous one because of the attestations of the current block, but still, I'll be skeptical of using PTC for this. Also, I don't think the semantics changes in Gloas. You're talking about slots, but… but the block that is confirmed is exactly the same as pre-GLAS. You're confirming the last block before So the previous last block that is being attested. Which is still the same. It's exactly the same as before.

Mikhail Kalinin: Yep, this is correct. But I think what matters for… for… Research is the confirmed payload. Not… not a block, so…

Potuz: Yeah, when I say block, I mean payload. So you're always confirming the previous to the last payload that has been attested. attestations at N are for the payload of N-1, so you're always… Confirming the previous to the last payload.

Mikhail Kalinin: Yes, but we run the fast confirmation rule at the start of N plus 1. So we… at the start of N plus 1, we confirm a payload… we confirm a Beacon block from N-1, from N, and the payload from n-1. This is how it currently works.

Potuz: Yeah, which is the payload, the latest payload, that was attested.

Mikhail Kalinin: I see what you mean, yes, I agree.

Potuz: So the problem is that…

Mikhail Kalinin: Congratulations.

Potuz: attestations are delayed, but the payload that you're confirming is exactly the same.

Mikhail Kalinin: I see.

Roberto Saltini: Yeah, the thing is that you don't… you're not confirming the… Fullness or emptiness of the… Right. That's the difference that you need. Alright.

Potuz: Right, so you should think of attestation-sRN plus 1, From the point of view of this, as an attestation for the payload of N. So instead of thinking of them as attestation for the CL block of N plus 1, you're thinking of them as just attestations for the payload of N.

Roberto Saltini: That's what… Causes, say, an extra slot of delay to confirm the inclusion of a transaction.

Potuz: Yeah, it should be half a slot, but yeah, so you, you could… But yes, that's correct.

Roberto Saltini: Yeah, that's why we're thinking. Perhaps the PTC can be used to… To, yeah, to reduce this delay.

Potuz: I think it's gonna be.

Roberto Saltini: Like, we have a.

Potuz: shrinky with PTC, it's… it might be… it might be very, very tricky. Like, there are some things that will cause a reorg. For example, if… if the payload takes too long to come… to execute. I mean, these kind of guarantees, we don't… we don't really have. But if… if a payload takes… And perhaps you should actually take this into account in the proof of the fast Confirmation rule, but if a payload takes more than the time allotted to execute. I think currently it causes an ex-ante reorg. So it doesn't… I think it doesn't change the things that have been already confirmed. But I think it would just, like, screw up with the fast confirmation on the next block.

And these kind of things cannot be seen by the PTC.

Mikhail Kalinin: Let's see. So it's… it's gonna be tricky, and… potentially unsafe. to rely on PTC, right?

Potuz: I cannot… I can't find a bug in relying on the PTC now. Everything that I… I mean, if I can think of anything, it's going to be about, like, the next block, not about the one that you're confirming now. But… but there are some subtleties to PTC. One of them is that PTC does not attest to validity, and it could be that the payload takes longer to execute, and it reords the next block, and it could be that the proposer doesn't have the data, but the PTC says that it exists. So… I don't know.

Mikhail Kalinin: Okay, I see. Then, EIP proposer… And have the data, then the, the empty proposal will be… Revolved, right, by a.

Potuz: Yeah, so all of the cases that I'm showing are cases in which the next proposal will be reorged, so in principle, it shouldn't affect the confirmed log, but it will affect the confirmation rule in the next log.

Mikhail Kalinin: Okay, I see Alright. Anyway, so this… this seems to be quiet. Difficult thing to… to do. And, yeah.

Roberto Saltini: Most of them will be, like, spec test work, and spec work, and… Yeah. Like, even if we can't believe that.

Mikhail Kalinin: Alright. Anyway, good to… Have this flagged. Have a discussion around this. And, yeah, another, another, another thing is that, there is a work in progress on decoupled Consensus. And decoupled Consensus will come with its own confirmation rule. Which basically… deprecates the FCR, the current version of the FCR? And doing this improvement, given that it's quite, resourceful, like, resource-consuming, might not be, yeah, might not be reasonable. Alright, the last point is, like, is research updates. Do we have research… any research updates for today?

Roberto Saltini: No. But we didn't also expect any of that.

Mikhail Kalinin: Yep.

Roberto Saltini: The part is concluded.

Mikhail Kalinin: Cool. That's great. Thanks, Roberto. Alright, before we wrap up, anything else to discuss or share today? Great, thanks a lot. Yeah, as I mentioned in the beginning, this is going to be the last recurring call. If any… anything… anything in the future we want to discuss, that will demand a call, we can set up an ad hoc one. We made a great progress. So far. So, thanks everyone for attending these calls. Thanks, everyone, for, you know, participating in all these. Great stuff. Yeah, wasn't… Great project, and yeah, let's continue and follow up in Telegram.

Yeah, yeah, yeah, Potuz.

Potuz: See you guys!

Mikhail Kalinin: Deal.

Roberto Saltini: Yeah.

Mikhail Kalinin: Bye.

Dmitrii Shmatko: And goodbye.

Jun Song: Alright, cheers, bro.

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