The Merge: Consensus API design space

[Music] okay so i think we should start um okay so today we have this uh dock to walk through and uh about the format of the call we will just go through these documents uh take some breaks for discussion and so forth uh uh yep uh i would like to like directly edit and add more info to this uh document uh right away um so let's just if if there will be like a rough consensus around some stuff that is not an option or won't be on go to standards of the api eventually so we will just make the comment and drop it the more important part i think would be to get more input uh on uh some stuff that is missed here that might be missed here like sync process we will stop for it in the middle um i guess the sync is not like explicitly mentioned here as a section uh yeah so but it should be i guess um yeah for yeah that's that's like the intro i'd like uh yeah yep you please don't hesitate to stop me at any point to make a comment or ask a question um if anyone rises hand i might not see it in time so just break me and yep and go ahead with your stuff so let's let's start any any questions i guess thanks very soon i'm turning on this edit mode um and thanks everyone for coming thanks a lot yeah glad to see you here everyone so uh the first thing we will start from is the title uh there have been a discussion in the um discord and all kardash uh channel so to i think we should do this uh like rename um this api to the engine api so the reason behind this is that we we have the consensus api which is the the api of the uh that is exposed by the software on the consensus layer which is the beacon node api uh which is the users and violator clients we also have the execution layer api which is the ethereum gsrbc it has several names namespaces we are not about to rename those namespaces but in general this is going to be like referred by the execution api and um yeah we have something in in between those two layers which is more specific to developers than users and like engine i think it's a reasonable um choice here to avoid uh to avoid the confusion and also engine is a bit confusing because uh like client developers may say that they have the consensus engine in their architecture design and they have this execution engine but it's less like confusing and then the other choice that we might uh might the alternative is maybe execution engine api engine api for short like the name space but then that kind of has a conflict with the execution api right uh so do we does anybody oppose to start using this term in applications this set of methods that is explained in this dock and that will go to the standard can you drop a link to this page in the chat to this yeah it's already there no no it depends on when you join on whether you can see it oh yeah yes yeah thanks mommy looks like i got one from someone okay so i think we're good with this let's move on um yeah okay so we are this is the design space uh we will uh shape shape with that most stuff remove some stuff um okay so in um yeah we are we want to reuse as much of existing service implementation which is obvious like the reason behind this the security of this api is critical and it's been agreed that it will be exposed on the independent port i don't think we should stop here for any discussion also we are picking up the new namespace name and we keep this idea that was proposed by photo to try to reuse the set of methods for the execution client try to use them on on the layer two solutions in the roll-ups in the clients that will uh in in the software that will be used to run those roll-ups so but anyway the layer one first uh and what can uh unify and what we can reuse on there too uh yeah we'll be like uh figure it out and yeah we but let's keep it in mind i think it's pretty reasonable okay so the encoding part i don't think we should stop here uh it's just you will use the it follows this uh like logic so let's reuse as much of the existing json rfc as we can so we'll use the encoding that is used by jsonpc it might be convenient to some uh places like but anyway uh it's we have libraries we have like uh intimidations channel list so yeah recording is here so the minimal set of methods it's been derived and the bit extended and modified from what we had in the in during the orionism um so let's move through all of them so there is the assemble payload which is the new name i think bailout is more specific and more uh like sounds uh to what we have uh so it just builds the payload and returns it back to the consensus client so the the addition here is uh from the previous uh variation the random uh but it's yeah it's just passing the uh randall makes two to the uh execution engine to embed it into the block uh there will be a corresponding eip uh to describe the specification on the execution layer side about this uh and what was added recently is the coin base um there are comments and uh there is the like a kind of opposition what was it um exposed by micah uh sorry martin yes um so regarding this method the sample payload which i understand to be basically please collate the block for me and put together transactions um the way it works now in each one is that man as soon as we have a new head we want to start mining immediately so we start working on the on the empty block then while that is happening the client is actually trying to find the best transactions and for mav yes i'm i mean they're working on finding the best set of sequences of you know these bundles and they keep working on it and improving it and from time to time updating the work package and i'm thinking if having just one method called assemble payload might not really cover then it it leads to the situation that the the um 2.0 sorry for using the term a client calls the consensus api and it needs to make it subjective like decision can i spend 100 milliseconds on it can i spend 200 can i spend two seconds on it and so i'm thinking it might be better to um first tell the consensus layer here's the latest tip and yes you are the one who's i'm going to ask you to deliver a new block on top of this in a little while because i think we know that when we when we have the new block that the next one will be our slot um and then later on we we the two little client can could ask like could you give me the new payload now um for the block that i already told you to start working on i know something like that maybe a bit more i don't know some kind of interactiveness might be if everything we're saying correctly you basically have uh two points in time one which is when the consensus client knows all the information that will go into the next block but it's not the last point in time where it's reasonable to receive it and you have another point in time later where it's like okay now is the last chance to give me a block right um i don't think that was quite what i meant what i mean is like if we're given a one-off chance to produce a block on top of some other random block there's going to be like a startup cost to to just you know figure out and get the state in order and stuff and then then there's this iterative process what what transactions should i fit it with and if we want to you know if the most pressing issue is that no we need to deliver something now then obviously we need to we're going to deliver an empty set of transactions um right so i guess what i'm thinking is is we have that set of details we can't start building the final block until we have those like four things right the parent hash timestamp the random and the coinbase i'm coinbase presumably you might know long in advance but like the timestamp and the parent hash but parenthouse definitely you don't know until some short period of time right before you're trying to build the block right you know because it's relative to the slot it has to be fixed to the slot it's a function in the slot and you know you know you're sorry the parent hash you know is is going to be from the prior slot so you have you know the block is coming in attestations are coming in likely in the four to six second time frame of the prior slot you know certainly you know without in in almost all cases that you're going to propose so you have that information so my my gut here is maybe you have um the method that doesn't like get block which is like the very basic method and then you have you know an alternative optional method where you can pretty much signal start work um and then if you signaled start work before you're going to get a better block when you call git block and if you call git block without having done that or prepare block m um [Music] then you're gonna get something more instantaneous or or a client underneath the hood could leverage that they're always trying to make a block from the previous tip uh and not leverage that extra method but the extra method maybe is you know an optimization uh yeah and do the does the is this optimization really critical piece i don't know as for me the strategy when the consensus client just starts to call the assembled payload in advance and calling it like several times and fix the latest block that it got from the execution client when the when it is time to propose the block uh so you're saying the alternative could be and i think we had this conversation many months ago the alternative could be once i know i'm going to want to block i just call symbol block over and over again and the execution engine knows that it should keep trying to make a better block because you might call it again it just makes a block so it it makes it by upon request so it's pretty simple for execution client to decide so it received the message how resource intensive is it to try and build that optimal set of transactions so it there will always be improvements that can be made because the pending pool is constantly changing and so even you know in the last millisecond you can get a new transaction in that totally changes what the optimal block is and so the optimal strategy for a block repair or block builder is to always try to build a better block every opportunity you get so as fast as you can you build better and better blocks um and as soon as long as transactions can even come in which basically always happens um there will always be some improvement you can make and and just um one more note so mikhail you mentioned that the it sounded like you meant that the this method could be called multiple times and we could get incrementally better but that means well how should the execution layer know that okay i can stop i can stop working on this now because sufficiently after time stamp it may finish like the work yeah it may finish like this work on uh i mean each request will have a corresponding response if it's not requested the block is not being built right but if it's if the working is scoped to the to the lifetime of the rpc request then you're saying it should not continue working after the rpc request stands i thought you meant it would right so actually we had this conversation with peter months ago and the the answer that we had come up with then and i think there's two sufficient answers one is that you do an explicit prepare and then you get it when you want it and the other is you call a symbol payload whenever you're ready and you get you get a response but timestamp is in fact in the future timestamp is the slot that you're going to propose at um which is either immediately now or is you know four seconds six seconds lead time because you know you're about to go so if you call it in those six seconds lead time you could on the execution layer know that time stamps still in the future and they're likely to call this again um and so that could be your signal to continue to do work and or not um so i think you can you can either leverage this method that way or you can do an explicit preparer and then uh and then i get yeah and now i get what uh what two alternatives do we have so uh one is the uh execution client is responsible for building these blocks and storing them returning uh the one that is latest upon re upon additional requests or remove this responsibility to the consensus client which will to do the same actually and i think if we have this functionality already implemented in the execution client it makes sense to keep it there and just provide this additional method that was what was suggested by martin right yeah and and martin there's a desire so there's a functionality to kind of always be building the best block but because we now know if we're going to actually want the best block soon then we might as well not always be building the best block and instead on demand be building the best block right because you could just keep it as is and just always be working on a pending block right does my correct understanding that the consensus client has a single point in time where they submit a single block to the network and they will never submit a second one is that correct correct for that slot for that all right so so there is at least the consensus client knows like now is the last chance for a block right right um the how much um like latency is acceptable there for that communication so like between the time the clinton's client says okay like i i want to submit a block to the network right now um if it takes 200 milliseconds to actually get that response from the execution engine is that okay or is that going to be a problem is it okay they're much better off broadcasting immediately at the start of the slot rather than like starting to do their work at the start of the slot okay so uh the incentives are such that that you know preparing so you should be preparing and then just actually get it out on time and that time stamp is i think i think the the prepare payload plus get payload is a lot clearer because it means when you prepare you can start get payload that is you just deliver what you have and if we have just assembled payload then it will be this you know um trying to measure how long have i spent time doing this oh should i deliver now can i wait another 50 blah blah blah yeah i think i agree it it adds some statefulness here but it as long as get payload can be operated without statefulness um you know without a previous repair and it would just give you something very quickly i think that that's a reasonable trade-off between statefulness and not yeah also one question here uh well how do the uh like the client decide when to like stop building one block or it's just constantly if we see one more transaction it will like build yet another block and so forth as long as you haven't done a get for the preparer then it would continue to try to build right so the uh it's like up to one transaction am i right i mean to yeah it should be relatively cheap to execute one transaction but yeah i don't know i mean yeah that's how often the block is the new version of the block is being built that's like my collection question are you in the game uh if we send this prepare payload how often will the block is being well the new version of the block is being built by the execution client so what is the condition here to start building a new one more of a modified one if i understand correctly is this depends on your transaction arrives and uh the new block is built like with a new set of transactions yeah so it depends on the particular miner and each all the minecraft strategies i believe and martin crack move around here that guest just every three seconds builds a new one while they're all proof of work is being worked on like somewhere else um if you're running like any v guest or something though um it's depend again depends on the particular miner but there are miners out there that are building constantly um there if this may be new block stuff that they're working on um you're actually getting full blocks from third parties that you then compare against the existing block you got from some third party so i think from a design standpoint we should assume that blocks are basically being constantly produced at maximal velocity through some potentially distributed network um on the back end so from the consensus client's perspective you know that you know on the other side of this api some amount of work is continuing to be done just until we call assemble block and someone's working real hard back there is what i recommend designing around yeah i think we should expect yes regardless regardless of exactly how that page right now i think mika mike you're that's the right model to agreed yeah so that was the reason behind my question that we might want to have like a new strategy in the stake world i mean for the vlog for updating the vlog okay so the consent centers if i understand really doesn't actually care about any of those intermediate blocks right they only compare care about the very last one they don't need to pull in between because they know exactly when they want to get the final result or the best result right like i would say that like three seconds might be a good a good one for work but yeah with the 13 seconds per block but here we have much less like twice as less right and in maybe that they're potentially not even following the same strategy so i think you should expect kind of a lot of innovation layer and expect potentially continuous work continuous and distributed i think that's this key to keep in mind like the thing you're talking to the execution clan you're talking to may just validate the block at the end like they might not actually be building the block they may have this work farmed out to the third parties yeah i i suggest okay yep sure so the the coinbase argument is it possible to have it only as a hint so validator can uh suggest the coinbase but the execution engine can decide to suggest different coinbase like i'm thinking about all the scenarios where we don't have a matching one to one between the validator like beacon chain and the ethereum one operator but some some scenarios where you have market where the uh blog builders are independent and can decide to have different strategy of coinbase and splitting the cash flows of the transaction fees and the uh and the rewards yeah that's a good question i think it should be an option for overriding the coinbase sent or like not doing the overwrite i mean the option in the command line interface for the execution client so which will explicitly say that the coin base will be overridden even though it's sent over this method will be all written by the following address around this node so if you need this setup i don't know if it's even appropriate to override it but probably in some cases it is necessary to have this kind of abortion but i think it was i think his question was in the other direction because you're saying there may be a default coinbase in the execution engine and this will override he was saying that the execution engine could say i'm not going to listen to you and use my own um which i don't think should be it should be designed in that scenario um and so i would i would have thought that it was optional in both directions that it's reasonable for someone running an execution engine to say actually no i'm i'm owning the coinbase i want these rewards because i'm running the engine i'm paying the costs for this it's also reasonable for a beacon node to not know what the coinbase should be so it doesn't supply one and it and expects the execution engine will provide a default and i'm strong on that but it seems to provide the flexibility that that kind of makes sense in terms of working through the use cases i think that um in a world in which we have a proof of custody for the execution of the uh of that layer that you essentially like the execution engine cannot be outsourced at that point and uh it needs to listen to what the directives are and that if a market is dictating that uh if the market makers dictate that they can set their own coin base and that you know that needs to be negotiated beforehand rather than uh not listen to at that point um i just i don't think it's very clear uh but there's a lot of active research working on making sure that you can't outsource execution like this and that you actually as a validator need to execute um even if somebody else is providing the payloads um and so i think we need to consider that the design i think the last thing you said is critical there the we definitely want to prevent people from outsourcing execution clients but i don't think that means we care about people outsourcing block production and the coinbase reward may make total sense to go to the block producer and not to um i agree but the model the consensus layer needs to like the consensus client needs to have actually known that they're entering into a market like that because it cannot validate like if it thinks that it's providing a coin base where fees are going to go to it can't it won't validate whether that information was actually respected or not so i think that it's it's very strange for the consensus layer to think i'm going to get these fees and then pass it along and then not have actually gotten it even if it's doing all the execution and stuff whereas i think if you were entering into a market where like that would be bypassed then you're you should have configured your system in such a way um so the problem there is that means that we need to know um like we'd have to negotiate the coinbase before we produce a block where we don't produce the block like if we're doing a market for block production the block producers are coming from all over and you don't know what the coinbase is going to be until after the block is produced like we have an order there that's going to cause problems i think right so maybe coinbase should be a configuration is it requisite that builders use coinbase to actually pay is there something there like you want to be able to make your engineer your block generic too and i think there's some like economic arguments of you know we want to encourage in 30 if your east actually be used for payment for transaction fees and coinbase kind of helps nudge people in that direction doesn't enforce it there's also like because there's a coinbase opcode it gives people submitting transactions a way to pay the block builder and so it gives a an auditable trail of payments from the people who are spending transactions so you don't end up with like uh layer two payments or some off other channel payments for this stuff again these aren't super strong arguments like they're not deal breakers but it just helps with transparency and stuff like that so let me see uh it's untenable for black builders to wait for prepare block before knowing coinbase address why is that the case so if the if you have someone submitting a transaction and they want to um bribe the person who is constructing a block they need to send money to coinbase via either via gas fees or via in a transaction they do you know coinbase.transfer requirements.call or whatever um and so they don't know who that who's that's going to be if you have a market for block builders so you might submit your transaction out to a dozen block builders and they're all competing with each other to try to build the most profitable block for the um block for the execution client or whoever slot is up right um but they want the people who are spending transactions to pay them because they're the ones who are need to be incentivized to sort their transactions appropriately and so we it's possible to you know have other ways of paying those block builders to just you lose transparency if you move it off to another layer can the can the consensus engine validates the the coinbase that's part of the blockheader right yeah so it seems like they could they could validate it but i think probably the more important question is what are they going to do about it they've got two choices they can either give up all their rewards and ditch the block or they can accept it and publish it and get you know the rewards on the beacon channel yeah and go up to coinbase they're going to accept it all right be me publish mpp as well like a good walk with the empty payload yeah i guess that's really nice i see the markets where the consensus engine actually speaks to multiple execution engines and then allows them to select coinbase and may have its own execution engine that it relies on as a last resort one where it knows that the coinbase will be agreed on so and then you can select of which one is the most favorable for the validator i think that's conflating this like block builder separation from like the validator actually executing things which in a world in which you have proof of custody on the execution layer the validator is going to fx have to execute things and so the fact that you got if and how you got a block from somebody and how it's paid for is kind of an independent thing and i i don't think that we should have this like super position where you're asking you don't know if the coinbase is going to be set even though you're going to still need to execute but are we assuming multiple conversations at this point are we are we assuming the consensus engine and the execution engine are a trusted relationship are we assuming they're i'm arguing that that will certainly be the case because it is a security flaw for it not to be um and there there's going to be a push in r d to make that the case over time that if you're running if you're if you're running a beacon node in a validator you have to actually literally do the execution um even if you outsourced block production or block building so in that case i feel like we could just say that the coinbase is a recommendation or it's like a just a place to put the coinbase then it's up to individual operators to decide do i want my validator node to decide the coinbase or do i want the execution engine to decide the coinbase and so this is basically a way to facilitate facilitate that communication but we don't have to like enforce that in any way we can just say you know it it's up to individual operators to decide which side um decides the final coinbase here's a mode for communicating that information between the two in case you decide you want to go with the model where your consensus engine is the one that makes the suggestion right i i think that's reasonable options here and there and it means that we uh like for the standard it would mean that we will use like not must said the coinbase uh organ but should or like the no with the notion that it may be overwritten i don't know by the execution client and tomas the what i'm arguing is that your execution engine might ask many market sources for a valuable payload but then your execution engine ultimately is going to run it and it needs to be configured to decide if it was happy with the setting of the coinbase or not um rather than the consensus layer talking to 10 different execution engines you know i think you have consensus layer execution engine and then a market for execution engine and and those are three different things rather than conflating execution engines as the market providers oh yeah i just used it as a shortcut so you can have an execution engine which is like an aggregator of execution engines but in the end architecturally it will still be talking to the consensus layer and therefore consensus layer it will be transparent however if we remove this ability to upgrade the coin base then the aggregating execution engine cannot really rely on multiple ones it can cannot even allow them to to act independently up front and try to construct different blocks and it actually what's cool about it is it's a bit more friendly for multiple solo execution engine validators runners so for solo validators it's might be harder to extract the mev so to create very efficient execution engines but they always want to make sure that they don't publish incorrect ones so they'll run the execution engine that will verify everything and validate but it will be like a default low value one but for the actual block construction very often they'll just redirect it to someone who can who can do that better because they can find them in v like so validators will have really really limited ability to extract mv which we see may end up being like 70 additional revenue so if we don't allow this coinbase to be overwritten then obviously maybe it protects us all validators in a way that they for sure will get the the transaction fees but on the other hand the block executors like the block builders may be less likely to um to provide any significant value because the the base fee of the burning the coinbase in the market makes it much more rigid is coinbase overwritten go on i might be healthier to to all of this to be overreading because it creates like this multiple execution engines that compete but also validate each other and and creates a bit more healthy market with like you can have liquid staking you're going to have big validators small mev runners and all like talking to different validators saying this is what i can propose you but i assume that you're running something to verify if i'm running the correct thing because otherwise it might be not voted or not attested and this would be a big loss for you um i'd stop here on the coinbase discussion so do we have like a legit case when we when the coinbase might be overwritten by the execution client or not i'm not seeing it yet because i think that the way that mev is extracted and and an open market doesn't need to override coinbase but i'm also probably speaking beyond my understanding at that point and i don't know if we're gonna solve that at this call i would say the proof of custody takes out most of the cases i can imagine it being useful um i don't think i think there's still i think there's lots of cases but i agree that we should probably move this to discord yep okay so if we have the coinbase here it implies that it will need to be um like it will need to be added to the later client api as well so this is for to consider for uh because it's flyable implementers as well so let's move forward um we have the these two methods um really really quick sorry mikael did we decide before we got distracted for the coinbase stuff did we get decide on switching that first method up to a um prepare and get so because that's engine we'll call prepare and then okay sorry i missed then yeah i i think we we have a rough concessions throughout this unless anyone is supposed to do that okay so yeah execute payload and consensus validated which might have an alternative name i personally don't like this much uh this one much uh so yeah uh wha what's here what's about these methods obviously we have the payload to execute and verify by the execution client and we have a big block to be verified uh by the speaking node um by the consultant's client and um it doesn't make any sense and the the payload even if it's a valid one but the consensus the the beacon block is not valid this payload might must be discarded this is why uh the second method appears here uh like the other option would be by sending the by calling the execute payload only after the consensus client has validated the beacon block and proves the proof that it's valid but it restricts the parallel parallelizer ability uh that we want to leverage uh the like meaning the parallel processing of the execution payload and the beacon block to save us some time hence we need these two methods and yeah there is like the resistance flow the sequence diagrams that illustrates how two different cases of how these two methods are combined um it also implies the cache in on the execution client side which is mentioned like uh like in the bottom of this document um like the execution payload will have to cache uh i will have stored in some place until the consensus validated message received and it can be easily discarded or persisted um for like i don't think any specific thing to mention here instead of this uh like uh that this uh consensus validated method maps on the proof of stake consensus validated event from the cip 3675 um and yeah there is the enumeration of it it just returns valid or invalid i don't think uh i don't know if known is valuable here probably not and same here it's just propagates that this uh the execution payload with this block hash the consensus uh rule set has been validated and the either electoral value because that's the these two methods the meaning of these two methods does anybody have any questions here i think it's pretty straightforward and just just make sure i understand so the execute payload will come in when the consensus engine is saying hey here's a block um let's go here yes okay block arrives the execution is descend and the consensus client starts to validate the beacon block in the meantime when it's validated it sends consensus validated so then the execution line responds and after all this done the block may be persisted or this or should be discarded there is another case when the execution won't be consensual late it comes after the the payload has been has been validated which is i don't think it's like potentially like the um frequent case um probably when the execution claude is completely empty no transactions that might happen but anyway it should be considered so that's the flow what what does an execution client need to do to recognize that um the consensus validated will never come good question you mean that when it should like drop the cash or yeah at some point the so the execution client receives executed payload it starts validating the block at some point i'm assuming it should throw that block away if it never receives a follow-up consensus validated is that is that true right or should it hold on forever right it may win for a finalized block event and drop the cash um yeah probably not actually if the okay so if yeah if if the payload is behind the checkpoint that has been finalized behind the block that has been finalized it should drop you should clear the cache so it should prune the cache in this case okay so so hold blocks until finalization and then once finalization occurs clear everything that's not in the finalized history but is prior to it in terms of slot numbers right and there is another possible case um when it could be cleared up if the consensus client was out but yeah that's uh that's related to the recovery of the failures and there will be an explicit uh place where the execution client understand that consensus client has been out if we follow the proposal in this document and in this case it can also release the cash like what was cached before doesn't matter anymore because consensus might just start it and will drop like new information like fresh information so that's two possible cases for flashing this cache for a drop in discussion um okay yeah we have like 10 minutes uh anyway um yeah the fork choice updated method it unifies the two uh previous methods that we have uh on the fork choice state updates which is finalize block and set hat the reason behind this um behind this unification is that the folk choice uh information uh namely the finalized block and the head must be updated atomically must be applied atomically to the block store to avoid the corner case uh which is rare but it's it can appear and it's alleged uh the corner case uh is about the situation when the like the new finalized block uh will be on a different fork than the previous finalized block and the message to finalize block arrives to the execution client and it should update this finalize finalized checkpoint and it will update it but after this update uh the head and the finalized checkpoint will be on different branches which is which is the um lack of consistency between the two and the yeah of course set heads that will update the head to the new uh to this new fork will arrive like in in a few milliseconds but anyway the world like a point of there will be a short period of time when these two uh two two blocks two two two things are inconsistent so that's why it needs to be um like the atomic update of the head and finalized block so the reason yeah i just want to note that uh given the discussions led by donkrid and and um maybe the definition of what is unsafe heads the most eager head than safe head which often would map to the same thing maybe with a little bit of delay and then also finalize i think that this would be the method where we'd actually want to insert that information those three things would always be on the same chain but if we do want to expose that additional information to the execution engine for the user apis that we discussed that i think this is where we would insert it um i would not propagate this information to the execution client rather would request it like from two sources this is just my opinion we've been discussing it a bit in this group uh just the the head block hash in this current draft that would be equivalent to what we've been talking about as the unsafe head is that correct yes oh yeah yeah yeah it's called that safehead you're saying you'd want to route as a proxy through to the beacon node rather than giving information right so because we might want to we might want to expose some other information from consensus layer to the user's api in the future so it might be more it should be more flexible and if we propagate this this all the information that the user needs to uh the user may request from the json rpc to the execution client uh this kind of like every every time we add something new to the fro from the consensus layer to the user's api uh we will have to update both the consensus clients and the execution yeah i'd argue not putting most of the consensus layer stuff into the user api and for them to be separate and if you actually do want to leverage stuff from the beacon chain run web3.beacon and ask for it directly i think this is an exceptional case because this is your maps to them understanding the head of the execution chain essentially and that it's relatively limited in the information and that the beacon chain is good at calculating it but it might as well hand it off to the execution engine because it's relevant to it but i obviously i think we could debate this yeah yeah yeah i see let's see i think the important part here is for backwards compatibility um unless we want the thing that everybody currently calls latest to be the unsafe head um we need to make sure the execution engine is aware of what the safe head is and i think it sounds like most of us agree that safehead is the reasonable replacement for latest and so the execution engine needs to know that in order to not break everything then what we don't probably agree on yet is whether uh the api proxies through to the beacon chain or if so that you can extend beacon chain functionality into the user api more easily or if this is kind of an isolated case and you just pass the additional information and don't proxy the api through so even if we did proxy i think we still need to tell the execution engine what the head is like regardless of the decision of proxy or not proxy the execution engine needs to know safehead so it can return something when users ask for latest various safe head is not finalized that is under you know if you if you assume the network is synchronous and you see sufficient attestations come in you can quickly know that it is very very unlikely to be reorg um and that that's kind of what we're calling safe here and then but that you could also be in a position where the head of your for choice has not had sufficient information to come in and it's still the head but it's not you can't make like as concrete you can't make as a probabilistically good of a decision yeah so we we currently have the the model that everything not finalized is unsafe for us so we're not like i agree that it might be it might be uh might be good to to publish a safe hat um to the user for the user facing apis but internally we will not um right do anything with it basically and i yeah i wouldn't suggest you uh the only thing that i would do with it is potentially um how you route it to the user apis in case i don't think that it has to do with how you handle your data model or anything like that yeah for context this is when it when a user through the json rpc api talking to an execution client using legacy apis only so they have not upgraded anything for the merge they say give me the latest block the estusion engine needs to return them something and we need to decide is that the unsafe head is that the safe head or is that finalized safe head i think is the best option here because it's very close to the tip but it's also very safe and whereas finalized is potentially pretty old and we don't want to give the user a block that's you know several minutes old and unsafe is unnecessarily risky to the user um okay so yeah get back to these like i do see while you in if we say that we propagate all this information to the full choice uh like these confirmations information to the execution client and will not get back to this pattern for any other data so that might be valuable and it might be reasonable to do once and yeah um also this yeah this unification requires the corresponding update in the 3675 because there are two um like events that this map maps on so this this is likely to be done soon um yeah um yeah we have like four minutes um yeah and it was we were great to talk about the scene but i i think we we have not we have not enough time for this so i i propose to reach out the gut team in discord to talk about the single find the requirements of the same process on the um on this api um and what do you think about making a call what is the better time for next call is like one week or two weeks from from from this so so we're currently working on on our part of this spec of what we think about the sink um which guarantees we can provide and felix is unfortunate not here today but he's currently writing down a new document with basically everything about the sink um so i think in one week we should be finished if you you all have like time there i don't know yeah i would make a call uh like one week after if uh like using the same time slots so any other opinions of that oh brother fork okay i mean we can use like half of all core devs or two-thirds of all cord devs to discuss the sake for the merch like we and it's basically it's not exactly one week and it's not exactly the same time but um it might be a good enough uh place if we can do this that'd be awesome sure yeah it's hard to see what's higher priority um yeah uh so i guess yeah just in terms of next steps uh america's like as soon as the get team has like a synced write up just posted in the all court as agenda and we'll we'll make sure to cover that first on the call next week yep and whatever time whatever whatever time uh periods during the awkward death so we'll have to go through we'll just try to do as much as we can like i mean just follow this discussion there um okay and stop sharing thanks everyone for coming thank you i was like expecting not reaching the end of the document today thank you so much um see you later thank you thanks everyone you