 Great. Hey guys. Hi. Okay. Should we start? Okay. So, welcome to the engine API discussion call number two. And actually this is the discussion session around engine API number three because we had an extra session during the previous ACD call. So, the agenda, the format of the call is the same, stays the same. So, if you want to ask Stamson or just put a comment, feel free to interrupt me at any point. If we are falling into deep discussion around some particular thing, we will likely break it and follow up on that in the discord in order to not like, like, distract the general line of this call. And also, we have an agenda for today. So we'll start from some small change to the minimal set methods that has been done since the previous discussion session, and then go to the transition process. And I'm not too optimistic that we will reach the end of the document today, but I think we should cover most important parts by the end of this call. Okay, so let's get started with the change to the minimal set of methods. The first one is that it's been discussed on discord, I guess, with Micah and Jim. And I think it makes sense. If engine prepare payload is not like if like building a payload in advance is not supported by a client. It should be implemented as a no op. So it will just do nothing, but the consensus client will will not have to adjust its usual more build and flow dependent on the client on the execution client implementation so it makes a lot of sense. And I think anything to comment here. What is the get payload limitation will now depend on prepare on this support of prepared payload. If it's fully supported then get payload should must return immediately with what has been built, whatever it is, even if it's just the empty payload. Consensus client will have a guarantee that it's response immediate, but if the like prepare payload is not is a no op is not implemented then get payload will work as follows it's just will go to the mempool select transactions from it build the payload and return back so it will go some delay. Also, prepare payload and get payload might be overridden by the like by by clients that are optimized for MEV. And in this case to prepare for the no op and the get payload will if there is the block builders in place, it will just return the fully a full payload to the consensus client. So it will also it should also work like it should also be an immediate return and yeah this is just an opportunity for MEV clients how it could be implemented. So the Micah. So, we can discuss this further in discord I thought we talked about and agreed to and sounds like we must understand each other that get payload would always return immediately. And it's up to the execution engine to, you know, figure out how to do that. If they're running MEV client of some kind that might just be, you know, grab latest block and return it because presumably they've already pre validated those, or if they're not running MEV, then maybe this return empty block or their return block they built previously but I thought that get payload is always supposed to return right away, like as fast as possible. And if you want to do more processing you should do it after you get the prepare. Okay. Okay, I see. So just build the block on the prep a lot and doesn't update it right. This is like the potential implementation, the potential behavior. If it's if the client doesn't support this constant data of the block that is being built. So you even that case like, I guess my assumption is from from like an API design standpoint, it's very beneficial if the, there are strong guarantees that the clients can rely on and timeliness of response to get payload is important because if you have if the client doesn't rely on a very fast response from get payload, then they can wait to the last minute to send it, which is desirable because you want to wait as long as the client feels is reasonable, because you're more likely to get better transactions more expensive block etc. Whereas if the client has to assume that the get payload response may be slow, it means they have to send the get payload request sooner, which means you have less time to build a better block. So I thought, again, we can talk about this more in discord. I think you and I must have misunderstood each other as all. Yeah, yeah, yeah, yeah, I get it. Yeah. And yeah, to agree that. And we specify like a time constraint that we would need to have a response by. The trickiness with the time constraint is that it's highly dependent on your like internet architecture. If you have your consensus and execution client both run on the same machine, then you know the round trip time is less than a millisecond and so you might have, you might be able to wait until kind of even more the last minute versus if you're running distributed maybe across that data centers or cross multiple machines across the world or whatever, then you need to send it much sooner. So I worry about kind of do it a protocol level time constraints there. Just because I feel like it's highly dependent on your architecture, like your constraint is don't use this message to start doing really hard work and instead to final finalize the bundling of a block and pass it along. Isn't, isn't that what prepare payload is. This is in the case for prepare payload wasn't called. So, yes, if it get payload is called essentially like should it at that point try to do hard work or should it just pass what it has which may be not something very good. And I think the implication here is past what it has. It might not be very good, or maybe it uses some sort of pending block structure, and it should just pull from that but it shouldn't be a an initiation to like do work that's going to take a second or three or eight. I think that prepare payload must be called anyway anyway, so it should be like a requirement so that get payload follows the corresponding prepare payload call. Sure, I meant if prepare payload wasn't no often. Oh yes. Okay, I thought you regard this wasn't called. And I have a question for what is the, what is the consensus engine supposed to do between the calls of prepare to prepare payload and get payload. It's supposed to keep listening to the big engine network and probably update the head. In between and the call prepare payload once again with the new head. So it may potentially issue multiple prepare payloads and then only one get payload is that's what you're saying. Right, if another prepare payload, the new primary say, right. Yeah, so it will the process of building a block will be restarted with like. So, so, so what I'm getting it is that the reason why this things has been split into two pieces right into prepare payload and get a payload is that because you might have a multiple of the first and only one of the second right. The initial reason is that the proposer wants to start wants to initiate the building of the payload in some advance. It knows that, like, during the next slot, or the next couple of slots, like the next few slots. It will have to propose a block. And at some point in advance it starts some point prior the slot that it's supposed to propose. And so it has all the information to prepare it but it's not yet the time to do it. But actually, yeah, actually the continuous nature of like proof of work where you're always about to try to, you're always trying to make a block. This is, I actually know I'm going to be proposing a block and call it four seconds. So I signal that the work is done and then I don't have to have this like pending block operation running continuously which apparently is pretty heavy depending on the implementation. Actually, yeah, this random parameter makes it no in this parameter I mean it is like is only known after the parent block has received so upon receiving the parent block it will. Every time the, there's a new head. The prepare payload needs to be called like after in order to start building the block from that head. Right, yes. Yeah, and also if, like the block from the previous slot is delaying. It could arrive later but the proposal might want to. So it seems to me that this reason the real reason why we have it right now not in the original reason is that you wanted to make this operation of preparing parallel interruptible so that you don't have to keep, because obviously you could run it in multiple threads and you know the choose the one that you wanted but you really want to interrupt the previous work to restart the new work. Actually it depends. Yes, I mean yeah, oh yeah we have an option here so we can add to the protocol that there is an option. No because I think it's everything else could be could be simulated with other means I think the I'm trying to understand the real reason why the real reason is that the, when we're speaking with death on a call previously is that there was only to get payload, which is implied that either work needs to be continuously done before, kind of like how pending block is done today, or it needs to be done at that at that call which can take a long time to get something valuable. And now that we know what the proposal knows at least four seconds before proposal maybe eight that they're going to propose and what they're going to build on, they can send that signal. Other than the continuous pending block work being done all the time, they can just signal to do it and get it. There's the exceptional case that you then might want to handle where there's a reorg in that timeframe, which is actually very unlikely. This configuration but you could get say eight seconds before I think this is going to be the head that's going to be built on I know I'm going to be the proposer, I send it. And then four seconds later I actually got a reorg, and I want to override my previous repair payload and then at the time of me proposing I call get payload. The, the motivator is, is the is the prior thing that I've said but then you need to handle the case where reorg happens which is why you might send to prepare payloads. Yeah, right. Just not. Any questions. I have a follow up question, is there any sense if like we get multiple prepay prepare payloads to construct multiple blocks and then one of them would be chosen on gate payload or is like, if we get another we definitely should cancel the previous work is there any like case for that. Yeah, I vote line in the, like section that is in the bottom of the document. Yeah, it might be the case when you're there are multiple consensus clients that are using these that are sharing one execution client, and they are concurrently and wants to build one the payload to be built on top of different parent blocks but that's an exception use case and should not be like. Yeah, I mean that's also implying there's multiple heads, which is not, I think generally how this API is being designed. Yeah, and it will have to support like multiple versions of mental from what I understand. If we want to keep building the payload on top of different and if these two heads are on the same chain right if this is if this is this are the parent and the child blocks so it doesn't make sense to keep building the payload on top of the parent block if you already see that there is a child. Yeah, in case of the child has been delayed and was running late. Just understand that the dependency graph. So the only time it every time the, if you already called prepare payload and then you call like new head with the fork choice updated. Shouldn't it just. I mean would you even need to call prepare payload again or would it. Just have it assume that. Okay actually you need to restart from this new head and the dependency graph is always like to build a block you need a head. Right but you should restart because this random parameter will be changed. It doesn't sound like correct choice updated. The random that's in there is only known by the next proposer is that correct. According to the current spec. Yes. But there is a PR. Yeah, not to mention a fork choice updated might even change the proposal shuffling and so you might not even be building a block anymore at that point. So, I don't think you want the fork choice to automatically interrupt this work. Is there a cancel build then in that case. Yeah, get a payload choice changes. You need to tell the next use engine hey stop building. You're not coming up next can also just know to cancel if certain time stamp has passed. It seems to me that like, you know, one thing I first noticed when I saw the separation is that there is this assumption about some state which is inside of the. So associated state is the kind of this makes it a state for API so when you do the prepare payload, it creates some kind of state that then you later rely on. Now we are coming to the, you know, just suggestion or maybe you should be cancelable. But then, you know, when you call the prepare payload, you implicitly think that the identifier of the state is parent hash plus random. So if somebody else gives the same pair of numbers than they will be referring to the same one. I think maybe it's better to explicitly return some kind of state ID than you can manipulate it doing cancellation or whatever you want to do, because there's there's kind of lots of implicit state here and then it might be that different. It might actually be complicating the discussion. I think it's technically stateless like I definitely see where you're coming from with it being a stateful because you're saying like you anytime you have you know a then be sort of situation. It's generally looks stateful. I'd push back slightly just because the payload actually contains the exact same information set. And so the prepare payload is more of just like a warning that you can choose to heed or not that saying hey, I'm going to be asking for payload later with these exact parameters. Feel free to start working because when I asked for it later I'm going to need it right now. And the excursion client can choose to not do that like it doesn't you technically you could have an execution client that completely ignores prepare payload it is not actually required for the protocol. It's actually required if you want to be able to have time to actually build useful blocks like if you're okay with not building useful blocks. You don't technically need it which is why I think it's it feels like it's not actually stateful just because it's more of just like an advanced warning system. Well it is you essentially not what you said is that the the combination of parent hash random is timestamp in there is that kind of this ID of this stuff which is. This ID it's more just like I'm about it's saying I'm going to in four seconds ish, I'm going to send a request to ask for a thing, and that request is going to ask for these something built the function of these four items. If you didn't get that for some reason, you would still get the follow request and you would still be expected to respond to the follow request just the same. It was just like a headset. Not sure, but you know there's a lots of different those questions if you don't specifically specify what is the ID then you say okay, what if I have one request which has got parent hash and timestamp but another one has the same parent hash but different timestamp. Do I need to keep the first one or replace it. I mean, you know, you know, of course we probably know the answers to all these questions but it would be good to specify what is the actual ID of the of this request, because basically kind of request ID or something. An execution client could definitely implement that by just literally just concatenating those four parameters or hashing them. And that would definitely function as a request ID and I can definitely appreciate an execution client choosing to implement that that way. And so that way you can decide, you know, okay this is the one that's associated with that like internal if your internal architecture that's more amenable, I think that would definitely work, because you will get the exact same parameter set in the get. So I would like to read the prepay a lot call as like in similar way as in the proof of work. The new block has come and become the head and you need to restart the process, which is constantly happening. The process of building the block. If, yeah, if this is turned on, I don't know if it's turned on or if there is an option to turn it on or not. I mean like the gas behaviors. So, any, anything to discuss here. I'm not sure what would cause this but what would, what would cause an execution client or consensus client not to send a payload ahead of time and for where they were just suddenly forced to just call get a load and then if we're requiring that it be immediate. But they just send something empty. I don't think it's expected that that would happen. I think it's just we need to design for in case like you just got a connection up for example and the consensus client had like as soon as your connection came up you're immediately up and so you only got to get says a hypothetical. It's kind of like how blocks are continuously mined and tried to be made better simultaneously and so very likely the logic would follow if you had to do something instantaneous that would be that like initial likely empty block with very little state transition and the hashing completed. Yeah, I agree that given the, that although prepare payload should be expected, and she is the proper way to run this API that give payload should be able to be called in the event of like weirds. I don't see any use case for that. I think it's failed a failure. So you could handle the get payload failure. I don't I think you don't want to handle that failure statefully though. I don't know. I don't see any use case for that. I think it's failed a failure. So you could handle the get payload failure. I don't think you don't want to handle that failure statefully though. I don't agree. There are some sections in this document that covers this kind of failures. Yeah, there is also the message ordering section which is new, which proposes much like just strict message ordering. And discuss it later. So unless somebody wants to say, I think you're a second question. If the execution client fails to fail to respond to get payload in time and you have to propose a block can you just propose a block with an empty execution section like basically like a beacon block as they are now. In this case, consensus client. Like, what does it mean fails to respond in time so it will respond later or what, or not respond at all. If yes posing it doesn't respond and you have a, you know, you have to propose this block. Will the beacon client be able to propose a block with empty execution payload itself. Yeah, theoretically it could be implemented as a fallback and with the time out on get payload response. But the state, does the state root change. If there's zero. No, it should not as we don't have the rewards anymore. I thought, so I thought that this glance could do fill slots without an execution payload and said not correct, or is that changing in the merge that is not. Okay, so there has to be something in that place and that something needs to be valid. You have to still essentially be able to chain something even if that something was empty. So I think that in general, we're designing under the assumption that you can make this request happen. And otherwise, your client, which is the unification these two things failed you and you were able to compute the hash. Okay, so it needs to be a valid block execution block header, at least, like that's the minimum required to fill a slot. Yeah, you could. I think that in general, we're designing under the assumption that you can make this request happen. And otherwise, your client, which is the unification these two things failed you, and you weren't able to produce blood. Yeah, you might be able to design some like logic and that you can chain client to be able to bypass this by hoisting some of the logic into there. But I don't. I wouldn't get on that. I agree with any here so we have a client and is, we have like the composite client and it's just fails to produce a block in this case to propose a block, whatever the reason is. And it should be identified. I mean, yeah, definitely be empty, like the failed proposal will be noticed by the owner and investigation will happen. And validators, they notice their monitoring, their monitoring infrastructure is so sensitive anytime, even they like get a non optimal attestation, even when it's included, they get warnings and they complain. Okay, anything else here. Next thing, I've added this confirmed block hash stuff here with the like tentative list of tags for Jason RBC, which will be extended from what we have now and there is the question by Terrence. So, and the proposal to like, for purpose earliest for the big subjectivity checkpoint, which makes sense, but could potentially break some apps, I don't know, or tooling that uses get blocked by another earliest to get the genesis. I don't know if this is really, really pretty in this case and important use case. Yeah, but we can discuss on this later I guess in this court or on the other. This kind of call. Okay. Yeah, also there is like the. There was the block persistent flow now there is the block proposal flow, which covers the like block proposal stuff. Yeah, there is a couple of sequence diagrams. That are the example of how the block proposal flow should happen. So we may take on it and take a look on it and get more understanding, I hope. So, yeah, so any questions to the minimal set of methods before the transition process. The process is also in the minimal methods like set. But it's something new with respect to, to the iranism consensus to see. Okay, so we will start from this one. So terminal total difficulty override. I would rename this to terminal total difficulty updated, because it's not only going to use for override but for also to set the initial value of the terminal total difficulty that is computed by the consensus layer at the merge hard fork, and then it will be updated to the execution client. So it maps on the terminal total difficulty property from the EIP. And yeah, it could be reused further to override the terminal total difficulty with a new value in case if we want to accelerate the merge. The corresponding full request to the consensus by extra repository that adds this possibility and yeah, the like scenario will be the following. The consensus client gets restarted with the terminal total difficulty override parameter, which she will. And this is how the overridden value will be passed to the consensus client and then consensus client upon a startup and connection to the execution client will communicate this overridden value. And the execution client must update this value and act accordingly according to the EIP specification. We should probably state and I think this is probably implied in how this event will be handled in 36.85 but probably say that it's a, you know, it's a no opera can be ignored if the transition has is in process or completed, maybe scope transition implies that. Yeah. Okay, I see. Actually, yeah, we should also add the corresponding event to the EIP, which says that that the terminal difficulty should be updated upon receiving this event and with this event will the new value. Okay, so there is. So let's go through like these two and then stop for questions terminal before block override is the another way to accelerate the merge. In this case, it, it overrides also the total difficulty transition based on the difficulty and direct with specifies the exact terminal proof of work block, and it means that the proposer will need to be started building the proof of block change to build transition block on top of this exact proof of work block. It also implies that the transition client, for example, should must stop processing blocks after this one, it must disable the blog gossip upon receiving this message, and some other stuff which is it which is not yet clear is specified by the EIP, but it will be specified like what once we once we get to this functionality, so it will be updated to the IP. So for this is also minimal set really just the first method is part of that minimal set like to get, you know, implementations going right. Sorry. What do you mean minimal set minimal set like minimal set to be a functional client or minimal set to on like the next wave of dev nets. No, no, it's like minimal required set for, or the other function client. Yeah. Okay, so, yeah, there will be a corresponding printer in the consensus clients that will set this value and communicate and then consistent client communicates to the execution like likewise with the typical stuff. So there be any advantage to using the block height instead of a block hash, you know, you only know the block hash right as it's, as it's been made the when it is blocked because in case of like attacks, they might be multiple blocks at the same height. And we need to specify the exact block. This is an emergency like coordination in which you're picking a hash in the past that you're coordinating on and you're probably taking some chain downtime to do so. Gotcha. And the terminal total difficulty is under, unless under like attack scenarios is superior. And we also you don't do the block height. You do terminal total difficulty because somebody can have like a cheap shadow chain that could reach a block height much faster than main net and try to take over the marriage so terminal difficulty shows and when you're taking something in the future. Yeah. So two questions one, is it expected that the execution clients will have a default terminal total difficulty baked in and they will only receive that message if there is the change or will they always can they depend on always receiving at least one of those messages at some point before it happens. They will receive it. It's not possible to know it in advance. So it will not be hard coded. It's possible but we, we, yeah, we decided to the decision was made to use the computed value. So it will be. So the execution client will always receive at least one of those messages is an accurate the terminal total difficulty override. Right. You mean you mean receive it during one session so at the end of the beginning of every session, it just gets one of those things right. That's the, that's a good question, like session of communication right. Yes, so because then it doesn't make an assumption about whether they stored in a database or they forgot about it or whatever. Right, right, right. So, yeah, it will be computed once but it should be communicated every session as you've said. Yes, I think it could be written in the spec that the consensus client needs to send those at the beginning of every session to make sure that they in sync. Here is the message. Here is the call that's giving it's like this kind of stuff, total difficulty and we will reach this place in the dog. Okay, so you may actually receive that status message but not the override that be accurate. Right, if it's been like. Yeah, yep. Exactly. So the, the override will happen only once when it is already or it's just set initially. So second second question, the for execution clients. Is it easier for any of you to have the block number included in addition to the hash for that terminal proof of work block override, like, when it comes to finding some old block is the hash always enough to never need a block height, like there's no database architectures that make are easier to find the block with height. My intuition is that it's straightforward to request by block hash either from the network or from the storage block has should be fine so something we just block us in the database. Yeah, that's as I wasn't sure if everybody's database has a index by block hash or some of them maybe just actually have like a linked list for example. The block hash we have also separate indexing by number but it's not from number to block but from number to a list of blocks, if you have multiple siblings. But by hush you can find both the main branch and the canonical and non-canical branches so by how she's the fastest way of accessing the books. So, any other questions here. If the session starts with communicating the terminal difficulty. What, like, then the purpose of these two calls is if you is so you don't have to restart a session. But if there's an emergency. Yeah, actually you will have to restart the session if it's the client will be restarted. So what is the purpose of these two calls then like how would it be different. Right, right. One can imagine a consensus client where you could override the terminal difficulty or the terminal proof of work block via an API without a restart. Yeah, I don't know if any of the consensus clients will do that but like from a design standpoint I can see that as being very reasonable. Anyway, it's the consensus client that sends one of these two terminal messages and they also start the session with information about the terminal. I see. So the both of them can change at runtime and one of the terminal difficulty isn't actually known at startup like today, for example, we don't know terminal difficulty. There will be a point in the future where we will learn what that is and it was sometime after the mergers scheduled and so ideally we wouldn't want to have to restart everything just to propagate that new information. Right, this could be sent during the session, and these two will be sent could be sent at the beginning of the session that be sufficient. Okay, but this one should be supported. But it could be supplanted by status message if we will eventually agree on adding the status one. So, moving on to get to work block. Okay, this is actually this has it pulls the same set of data that the get blocked by hash. The only difference here, and this is important is that the execution client should request these block that request by this hash from the wire. If for some reason it hasn't been received from gossip. And, yeah, we might not want to implement this method and instead use the get blocked by hash but imagine the case when the whole the node stuck at the transition because it hasn't received the terminal approval for block wire gossip. I am wondering how likely this could happen. And yeah, if it happens, only a manual restart can help to recover from this case from the situation. So it would be great if we have this one, but I'm open to any opinions on that. So, what exactly is happening with. When, when would this be called. When the transition block is received the transition block is the first proof of stake block in the system. And this method will be used to pull the parent of this block, and the parent of its parents to verify that this is the value terminal for the block. And, yeah, this code is is running in the book choice of the consensus client to accept the block. When you call. So it's, it's, I have a proof of stake block, and I'm concerned whether it actually was built on the terminal total difficulty block, like on a terminal to the view block and I use this to. Yeah, you may use this but it doesn't has this property of making the client to pull the block from the wire if it's missing local storage. So it's basically saying because this client is saying there exists a proof of work block out there that we are very confident exists if you don't have it go figure it out, like do whatever you need to do to get this block. Whereas get get blocked by hash normally it's like, hey, here's a hash. Let me know if you have this block. I want it be more authoritative here because this is the point where the proof state client is, or the client is taking over right and so they're saying you will, you must have this block for me to continue working. Is that accurate. Right. Otherwise we're getting stuck here and they imply that when they run execute payload on the transition block to because execute payload has the parent hash. And it's pretty much saying you must have this parent hash, and if you should go find it otherwise I'm not. I think I'm not understanding what exactly this message is for. Um, you're not executing payload, you're not executing payload during the folk choice. Right. So you're checking that this is the right. This is the right proof of stake block, like the right transition block. So, with respect to the transition process not with respect to the, like, execution yet. So it will be executed later. But at this point you just want to understand before falling into the state transition function. And what is, what is POW block, is that include terminals or with the unit or something. Yeah, let me open it here. So here it is. It has all the required information here is what's going to help me. And here is the code right. So it's before the state transition, and it's important to be before. If, if we get stuck here. So we're not doing the state transition and that's it. So the client wants to know that this is actually a valid terminal group of work block that when it sees the initial transition process and the exists the other methods don't really help us ascertain that. And so there's an exceptional call here on this transition to make sure that somebody didn't create like a bad transition block. Yeah, because it might be a valid transition it might not have picked the right parent block or valid parent block. Okay. I suppose that payload can can do that though for you, because execute payload knows the terminal total difficulty and could tell you if you built off of something invalid, but it might be good to just be explicit here. The execute payload actually doesn't tell about all the difficulty, but we can check it inside of the stage position that is what you mean. I'm saying the execution client knows about terminal total difficulty. And so if you did execute payload and it was the first and execute being built off of a work block it could know if that was not. Oh yeah you you mean we can you we can defer this check to the execution client. Yeah, I'm not convinced that that's correct I just am now understand why this why this exists. Okay. Okay, I want to think about a bit more. I don't think I much more say I'm not. Yeah we have already some implemented we can use this one, but as it's been said, it doesn't go to the wire, if the block has missed. The question to the execution plan mirrors, how often the, you know how often how likely the gossip to be to not deliver your blog or its hash. How often do you do you do your like clients have to go to the wire to pull the parent of some blog that you have received but some reason you've missed the parent blog. Yeah, I agree with Michael, but this is fairly unlikely, but it happens especially on like some network blips etc. So yeah if you say that we are pretty confident that that this method will work. Well, so we will just remove these from the design space. Well, it might not work but we're kind of thinking that the, the, the, the probability of this occurring everywhere it's very small, like it might occur in one or two nodes or something. So it means that if. Yeah, there will be a very little portion of nodes that might get stuck right, even if we even have this kind of notes. If you, if you follow the like execute payload path, I think the input implication is that execution execute payload if it couldn't, if it didn't know the parent would go find it with the network so it might be better to just run that path. Then we will have to get to this check after execute payload right after the state transition. And the execute payload will actually has an additional semantics for the transition period. It will need to go to the wire and pull the block if it's it and pull the parent block if it's not in the local storage. It already, it already has to do that though right in order to validate the current block you need to know what the parent block was, you need to have seen the. Right, right but currently consensus client guarantees that that all previous blocks has been sent to the execution where that that I think actually when you start talking about failure modes and synchronization issues between these two pieces of software that like the what we've previously discussed is, say, say the execution engine fails it gets restarted and it's 10 blocks behind and, and the big change client inserts a block that the execution client can then say no I don't have the parent or it could actually just go to the network and get all the recursively look up those 10 blocks and handle itself. That's not out of the question that yes your side actually does do some self mending when it doesn't have a parent. Yeah, that might work. But if in this case execution client falls into the state sink to pull the state. And the apple headers it might take some time. Which is what we are transition process like it's time critical. I think the parent block from the wire may also take some time but probably it is like. Yeah, but probably it will have to pull like one block and it's parent and supports. Yeah, so I think in, in all happy paths that should already have the parent block, I think the primary unhappy path is when someone act actively is attacking the transition, and they have mined a the first instance block on invalid terminal toad difficulty proof of work block. That's the time where you would maybe get a request to hey execute this block. The client doesn't have it because it's not a valid block and it never accepted such a thing. So we are like roughly agreed that it would be better to rely on to get one hash right and on the blog gossip. I think I'm with Danny I prefer relying on this executing the block later but this might be a good conversation to move over discord since we're out of time. Right, right, right. Okay, the next one is sync. Well, like, great work done by Alex and get them on the nursing proposal. I've outlined like this, this thing status was in this document before but there is the same checkpoint set, which is required by which is, yeah, is one of the required methods here. And the, to make the execution client aware of what is the block header at the big subjectivity point. And consensus client knows that what's the header is because it goes the state of the subjectivity checkpoint and can directly send it to the execution client. This is also the first step of the same process. So it's like initiating the same process. And also might be a might be a clear evidence that the execution client should switch to the proof of stake mode. So, I, yeah, a bit of context on that. The execution clients after the merge. Yeah, after the merge happened. And before any execution clients were updates, the execution clients will start in the work mode by default, as they don't know that transition has already happened. And, yeah, they will go to the network to look for the blog and the PS with the greatest difficulty value and so forth and listen to the blog gossip and other stuff. And, yeah, we'd like the consensus client to inform the execution client if the transition transition has already happened. And this is how it could be done. So, once this checkpoint set mess message send aside from the initiating the same process. The execution client may switch to the proof of stake mode and listen to the consensus clients instead of listening to the blog gossip and doing some other stuff. This has to be sent. This is have to be sent every time the execution client is started. I guess no it's it should be sent only on the fresh client start up when there is no box or state and the local storage. There is already some state. It should not be sent. Checkpoint said, actually, it depends if you're behind the week subjectivity checkpoint that it should be sent again, I guess. No, because you just said that it automatically it starts with a proof of work mode and that sounds. It's in the proof of work mode because it's fresh client and it doesn't know about the transition has happened on the net. Wait, but we are going to put the transition difficulty like into the heart for for proof of work as well right. I want to avoid the situation like imagine post post like post merge someone X someone's exit. Sorry, someone's consensus client accidentally crashes right. The execution client restarts. And now they are in proof of work mode but they don't know it, and that that will automatically use some proof of work chain that's like, not really the theme chain. Right, but that sounds dangerous. Yes. But if they start. Yeah, this like switch, I think it should be persisted by the execution client. So it will just start up in the state mode if it's been informed about it previously, even after it starts. And, and also the proof of work client should, if it ever received and saved the terminal difficulty, it should refuse to ever accept any blocks beyond that right. Right. Yeah, exactly. And also, shouldn't we put the default value for that just in the client as an in the source code so that it doesn't have to like what if someone just keeps running a proof of work line without starting up there be compliant at all. Then once again they could end up in a situation where they keep following the proof of work chain. So I think the default behavior should be to stop like all proof of work lines should ideally just stop working if they aren't connected to consensus client. All other behaviors are going to be extremely dangerous. I thought how do we handle the transition process. Do I thought we didn't know the terminal difficulty until like a week before the merge or something that change. I haven't followed that closely. Yes, so it will be communicated like and we can't hard code it because it right right we won't know until after everybody's deployed their clients. Right. Why can't we just like do it but like with other hard folks who we all agree on one block height, we keep the I mean I thought the end points to set it are for emergency like if you say like, oh we need to change it. But like. Yeah, I'd stop here and let's continue with this discussion on this word, because we have one minute to the next goal. Okay, thanks everyone. See you soon I guess. Bye bye. Thank you. Thank you.