EngineAPI | Mikhail Kalinin

welcome everyone uh to today's uh study group lecture on engine API so uh we are in week seven of our study group having deeper into ethereum and today we are uh learning about very important part of ethereum which is actually the uh sort of the heart the connection between the consensus and execution layer and it's my honor to have mik here because he was essential in designing engine API he was uh uh I like your title here research engineer like I think U Mikel is really interesting to talk to because he's really like between the engineering and and uh the research so uh so uh he will give us a great insight into into the origin of engine API and how it works so yeah thank you so much again for being here and the stage is yours yeah thanks a lot Mario for this warm welcome um yeah so thanks for introducing myself so will not uh you know um spend much time on it so as Myra said I'm a research engineer uh working at consensus and uh uh today I want to cover the engine Epi design rational basically the core uh things uh and reasons uh why uh the engine API has the shape as it has today uh because uh I feel like we lack this information uh somewhere out out there so we lack the resources that people can really use and learn about the rationale uh of of this uh API um there is the resource uh like that uh this very useful uh showing how it works actually so how the which methods and uh uh responses are between the um method calls and responses between CL and DL but yeah uh this this time we'll talk about the design rational so let's I I'll just try to cover it and make it more clear probably for um for you and uh many others okay so um I'll start my talk uh uh from from some um from some trip to the history uh to the early days of the engine API and uh uh the first appearance of this concept happened in uh five years ago so there is basically uh the eth research post by Daniel Ryan uh who proposes has proposed the uh this separation of concerns between recording has stopped sorry Gord has stopped yeah no worries no worries we have a backup um just go okay okay yeah worries okay so um this uh oh yeah I should have said that five years ago we didn't know how we will do the merge exactly like so it was not a given uh we were uh seeking for you know for Solutions and uh uh Danny basically proposed the um idea of uh separating the concerns uh between uh the consensus layer client and execution layer client uh so you can on this slide you can see E2 and E1 client and engine so those are really old names that we used by uh back in the days and uh to highlight uh the um the the idea uh so it's it's basically like uh Danny proposed uh that the E2 client will uh be responsible for the consensus part it will uh produce the Bon it will uh process the beacon chain and uh basically run the consensus protocol uh and uh this consensus protocol uh will uh uh will come to consensus on the um on the Bon chain and this Bon chain in relation to the execution layer chain uh so this relation was not set by that time but we were thinking about uh the execution layer part which will manage the ex execution layer chain uh because it has evm uh already has evm it the it has the E1 State the world State Management uh it runs the transaction mol so it actually um is buil in the um the the blocks the L blocks or the pays as we call them later on and in this relations between these two clients uh the consensus layer client was supposed to be uh driving uh the execution layer client as it is shown on this uh picture uh and uh what's proposed as as the communication channel uh the JPC was proposed as the communication Channel because uh El client by that time was already equipped with jsonrpc uh API uh which was U used by users to uh query blockchain data see the transactions included on chain and do other stuff do other more fancy stuff so yeah that's where the first uh idea of the engine API appeared um and then uh during this the same year um Gom from G team uh actually uh developed the first execution engine uh the Prototype of the execution agent based on gath uh which called Catalyst and this uh uh execution engine client already had uh these three um uh API methods that we used uh to prototype the first um kind of like merge uh merge like uh client pair uh where there was a CL part and El part the catalist or on the a part and here basically we see three methods Three core uh methods that are still used today um a lot of details changed since that time but those three things which is basically in certain block uh um setting the hat and producing a block they did not change so we will uh on the next slides we will see how they look today and yeah I think naming is very important for engineers and the name engine was proposed by prot Lambda and thanks a lot for this name I think it really reflects what this API is about as opposed to the E2 um prefix that we had in the first execution engine okay um now yeah since yeah the History part has uh finished we went over it and we can I think start talking about the core um of the engine API how it looks today and uh yeah I don't know if there are any questions so far um I guess not but maybe yeah okay let's just move on um so um the yeah so the um actually the blockchain client is the even driven system and uh the CL client and El are event driven and yeah so we will use this uh it makes sense to outline the core events that happening um while processing the blockchain data and uh the corresponding engine Epi methods that are used to handle those events um so the first one is new block so new block is received from the network um and in this case in the case of this event consensus layer will start uh processing this blog will uh validate the consensus data uh will process attestations pay rewards and all this kind of stuff and uh throughout this uh block validation on the consensus part the consensus layer client will also uh which is uh very important will also uh call the new payload method on the ex execution layer uh on the execution layer client side which will be which answers the main question whether this pay Lo is valid uh from the point of execution so whether it's well formed uh like whether the uh the payload like uh corresponds to the block hash that is coming within this payload and what is more important whether this payload is U yeah whether transactions included in this payload app bid and correspond to the state root um of the payload so the next one is update head so the whenever the more consensus data processed like new attestations are coming new validator votes are happening uh new block arrived or whatever so whenever the consensus U protocol um comes to a point where the the head of canonical chain uh is gets updated on its side it sends this propagates this information to the E client uh and uses the folk Choice updated method to to do this um to propagate this information and also the F chice updated has uh uh additional semantics uh which is to start the payload Bill process and uh we will talk about these specific case later on and figure out why uh this method has basically uh two semantics um so yeah so and update had can actually happen without any new block arrived so just basically by receiving more attestations in favor of more votes in favor of one block uh the consensus layer can make a decision to switch the hat to that block and yeah this is this is how it and is just basically sense the FK Choice updated message uh signifying what is the current hat so and the last bit uh of uh of this um part uh is the block building so we obviously need to build blocks uh to to keep uh to keep actually building our blockchain and keep including transactions into a block uh into blocks into blockchain and yeah there is a block build block functionality that also uh requires communication with El because El is responsible for building a payload and uh the payload payload build process triggered by the F Choice updated and there is the uh method that obtains the payload that has been built which is called get payload so that's that's it um can you hear me is it fine awesome okay so um a bit let's dive a bit deeper into a couple of the main methods which are new payload and for Choice updated so the new payload here is called when the new new new block is received by CL and what's in the request in the request is basically the payload itself and some additional data that CL sends to e so these data I'll I'll talk about them a bit later um execution so then how how this method is actually handled by the El uh first of all El validates the block hash it computes the block hash and matches the one that uh is given uh by CL as a part of the payload it is very important for uh for cl to know whether this block hash is actually valid um and uh also uh uh here we see that the execution request which is new to new to ptra new newly introduced inra this of information was not uh is not now on the main net but will be soon uh yeah it's also kind of like U validated by El side um there is a commitment in the El block header um that uh is um yeah the commitment to actually the execution request and it is important for y to validate it as well uh there is also expected block version hashes uh actually so it it uh what I would like to highlight here is that the E does some uh validations some preliminary validations uh um uh that are requested by CL so CL it is important for cl to know that execution requests a valid uh has a valid commitment it is important for cl to know the expected blob version hashes are uh the one that are contained in the payload but but why then then the reasonable question is why CL does not do it it is basically because uh to do the to run these validations uh for instance to run the block has validation uh CL needs to uh know how to compute kitak to 56 has function and how to compute rlp uh which is completely something uh that c is not aware and should not be aware of uh for to validate The Blob version hashes uh CL would need to parse uh transactions so it would need to learn uh the El and Co the El specific thing thing which is transaction encoding uh so CL basically defers all these responsibilities to El this what matters this what is important so this is where this we see the separation of concerns and practice uh it's not only to run the uh transactions but it also to do some specific uh encoding and uh cryptographic primitive checks that CL is not aware of so we don't want to introduce our and kak on C side and yeah this is why it is here uh and yeah after doing this preliminary um validation actually U the payload is executed by El and the corresponding status is returned whether payload is valid or not um the parent beacon block route uh is used in the execution and it actually the bit of information that consensus layer propagates to the execution layer and this uh parent beacon block route is uh kept in a system smart contract there is a history of parent beacon block roots that are reside in a system smart contract on the E uh so evm uh so this information is uh can be uh accessible from the inside of the evm so other contracts can use it um and this is very uh there are many useful uh use there are many uh use cases for this um parent beacon block route so on one hand we have a separation concern of concerns and uh we don't do unnecessary things on CL side but on the other hand uh we have like a more tight uh relations between CL and DL like pass and the parent beon block route so can store it and actually expose to um to to the application later yeah so next one is FK Choice updated is basically uh the main uh payload of this call is the FK Choice state so what is the head block also what's fast is the finalized block and save block uh finalized block is used for even uh for is used to to be exposed in the jsonrpc API to to to the um consumers of of jsonrpc API um and yeah it's also probably used for um El State Management yeah but what matters the most here is the head block and also in the request can the payload attributes uh can also come in in the request and uh these pad attributes uh is uh are passed in the case where um there is a request to start building a new payload and they contain like this parent beacon block route Tim stamp and other stuff other bits of information that El needs from cl to actually build a payload and this this this part of uh of request is optional so if payload attributes are not coming uh the payload build process is not started yeah so the execution is simple the hat is updated to the one that is given um and uh yeah and the build process started if needed so it's like simple from the um from the surface but uh under the hood it's it's quite complicated in terms of implementation and there result also the payload status in the response and payload ID if the build process has been SED so the get payload will use the payload ID to obtain the payload later on um okay um if there are no questions and I want [Music] to okay um yeah so now I want to talk about about about Bon uh Bon blocks and payload relations uh so this is important for understanding um for for the context that will help understand uh the next part of the presentation so uh actually uh so we have a we have a blockchain um uh which consists of a bacon blocks and every bigon block has a payload so there is no way for a block to be empty and have no payload the payload can be empty itself so it can have zero transactions but every beon block has a payload um and uh the payloads are also uh form in a blockchain so the the every payload has its parent uh likewise the every Pon block has its parent so we basically have one blockchain encapsulated in the other one and this inner payload blockchain um it has a onet to one relation uh like the one to one relation with uh the the outer blockchain which means that um every pay uh every payload has only a single Bon block it is wrapped by and the other way around every bacon block has only a single payload um which is important so we have two blockchains but they are very tightly coupled and and they have a um and these and bits of these blockchains has a onetoone relations so and uh on the next slide I will mostly talk about payLo Al blockchain like which is the chain of payloads um so but you should also understand there that there is the U uh the pick block wrapping every payload okay so uh let's go to the uh let's yeah let's just cover how the block processing is happening yeah so yeah I imagine this situation that the new block has received uh suppose it is a Block C and uh currently uh the our uh node is in a state where Block B is the head uh the consensus layer and execution layer has validated Block B and block be payload uh and consensus uh layer actually after executing the consensus protocol um decided that b is the head and uh the El also knows that b the payload of B is the head of the um of the chain so the new Block C is com in um the consensus layer uh starts to process it it finds that the Block C is the child of B uh it starts to process the conf consensus information and at the same time uh it does a method call uh it does a new payload method call to Y um we are in a very happy case El has all the information it knows its parent uh the parent of this payload it has the state uh which is the state of the of uh uh which is the post post state of b um so the post state of the uh of the payload c um parent so it it can actually just do the run all the validations uh check the block has uh check the um other bits of informations that are coming from consensus part and then execute transactions so it does this in a synchronous fashion in this case so El synchronously uh executes the payload and responds to CL uh so that suppose the payload is valid but uh yeah CL knows learns that the payload is valid it's fine it's great uh but no but you should notice that uh the head is not yet set to Block C so there is no way uh where the C becomes uh the head without the fork Choice updated uh method call so when all the validations are passed and on this CL side and cl is aware that the payload of Block C is valid and uh then the CL side runs its FK Choice function and if this FK Choice function returns um Block C is the as the head uh CL will send this information to to El and El will set the block here is the hat only only after that so this is how the like heavy case block processing is happening um so yeah let's let's consider re walk what happens in case of reor um suppose we uh our Block C is the head and the block D which is not a descendant of C which is not a child of C comes and block D has a block b as a parent so new payload method called um yeah says that okay the payload D is valid it's fine and then um CL decides uh calls the get head method on its side and it appears that D becomes the head and then the F Choice updated message sent to um e to to signify that D is d d is the new head of the chain but uh yeah suppose sometimes past and more votes are coming from the network and cl observes that uh bo C is the head again so it's it uh it becomes the new head so D is not the head anymore and then uh the FK Choice updated method call uh is done by cl to to set c as the head so this is the case which can uh which is quite common for uh the real for the main net and for for the real network uh where without any new block um the Hat can be changed and even reset back um depending on the situation so this this what happens and this why the fur updated method uh is important and why it can be called without any new block information so it's just yeah switches the hat to to to to the other block at any at any point in time so e is not aware of what is happening on CL side this is just cl to decide so CL drives uh this communication as we uh remember from from the first slide yeah so now let's let's quickly cover the payload building um so here uh we have the for Choice updated it says the Block C is the head and also sends the payload attributes to build a block e so this is because on the C side uh um this heel part uh observed that it will be a proposal in the next slot it won propose a block and it sets the payload build process in Motion in this case uh yeah in this case P ID is returned and then uh this build process will take some time um and uh yeah El will be building uh the block on top of Block C will will be backing transactions into this block uh so it's uh and at any point in time uh El should be ready to um return uh whatever it has built till till the current moment in time so the CL will is called get payload with the corresponding ID and will receive the um payload that has been built uh blobs execution requests and all the information that CL requires from the side which is not a part of a payload um and uh uh this FK Choice updated uh method has a double semantics um as we mentioned before which actually breaks the single responsibility principle and uh most of the designs isn't uh that good but in our situation it is quite reasonable because the El clients can only run the build process can only start the build process and can only uh keep building a payload on top of the head of canonical chain so these uh two events the these two things uh must be atomically processed by the E like setting the head and starting the build process because starting the build process uh on the on on the Block that is not canonical hat is the failure mode which in this case uh we would have to handle somehow so if it were two different methods uh we would need to uh to ensure some failure reme for the case where uh payload building requested on top of non-canonical block or we would need to have to somehow synchronize them so the decision was made uh just to basically make them um make these two things um into one method into one Handler to avoid the situation where uh where we have a some racing and uh yeah which leads us to failure um so that's that's the um answer to why the payload building is tightly coupled to the U to to to updating the Hat of the chain okay I guess we have some questions yeah it it doesn't mean uh so the case I was uh mentioning uh doesn't mean the slot is empty so the Bon block is proposed the payload as a part of this beon block exists but this payload has no transactions Um this can happen on some I don't know devet which lacks of transactions in the M Pole or in some failure remote case for say some CLS maybe are doing it today or just did it you know in the past uh if El is not responding uh CL could uh just propose a beacon block with empty payload and would craft this empty payload by themselves uh just not to miss the the um the proposal so in this case this would have the beon block but in the payload because we have this one one to one relation Bon block must have a payload but the payload will be empty yeah yeah so yeah the next sorry yeah so I think there is a question about why the um you'll have to know what is the head of the chain yeah so yeah that's a good question uh first of all um yeah first of all El needs this for its uh kind of inner purposes to um to manage the state uh to to do some uh all all to to actually do the um um State pruning uh this is some something in the weeds of the State Management of Cl also it needs it this information for syncing so it always needs in during the sync it needs to understand what is the head so which data El needs to pull from the network and these data are identified by the hat so whether it's a state whether El is in a state sync mode or whether it's a uh block sync mode where blocks are pulled from the n Network and import it it needs to know the hat and I think uh the other very important part is the uh jarp API uh it is very important for um blockchain data consumers to know what is the had and since the Json RPC API so the API for uh the application layer is still uh served by the execution layer client the the notion of the hat is very important likewise the notion of the finalized block so e needs to know about finalized block because uh blockchain data consumers can basically say okay uh what is the most recent finalized block yeah it's is this one whether my transaction was in in this block or in one of its parent or sorry or in one of its ancestors um the parent or one of its ancestors so yeah this why it's Fork Choice information is important it's used by the by the blockchain data consumers okay yeah yeah yeah and death P2P is used uh to manage yeah manage meol transaction meol and to do the sync and uh yeah that's this this is very important part of e but uh yeah but if yeah but if CL and El are uh on the same page they CAU up with the head of the chain basically CL will just send send the new payload method calls new payload messages to to El and El will not need to uh to request this information from from the peer-to-peer so it will be given by C it's only needed in the sync mode okay uh now yeah so we yeah uh let's move on uh so before uh we were like considering like simple scenarios where we have all the required information to answer the question whether the payload is valid or not to execute this payload transaction we we covered reorgs as well uh um and yeah payload building so all all these cases were like where CL where El has all the information uh to to process payload to build uh the new payload and so forth but what if not so here we uh go to the sync uh how the sync works and how it affects how it impacts the communication between CL and DL so uh let's consider the case where some blockchain data on El side are missed uh cons let's just for for Simplicity say that some aage happened and uh the the note was just shut down for for for several minutes maybe for 10 minutes and it was sorted up so say that software upgrade has happened um and during this um shut down during this maintenance um when the node was shut down CL and El a bit diverged on on the the most recent imported block so say eel uh for some reason a couple of blocks from from El uh database was just you know Lo lost dropped or whatever so we just lost a bit of blockchain data but C still awes that Block B um that was previously validated by uh the ex execution layer uh yeah it's valid and C is the head so C starts up and what actually happens uh it it pulls off uh on the C side it just pulls off the block D which is the child of c and start sending this um the payload of this block uh to to the e in this case El um doesn't know uh whether it ites doesn't know it doesn't even aware of the parent of this block so Block C is unknown to e and uh uh in this case um we have a special status for to handle this uh case which is called syncing and uh yeah in this case uh while in the payload execution everything happens synchronously so the sync process is happening asynchronously um so El will be doing sync process and the CL will in this case if El is in in the sync uh CL will be just receiv receiving syncing status um uh when send in a new payad and when send in fure is updated so the syncing status will be returned and uh as you you can see on on this diagram uh once uh say that e cut up pulled off all these blocks from from the network and able now to validate block D it actually validates it and responds with a valid status um and uh yeah from this point CL aares that uh El has all the information uh to keep to keep up with the uh to keep up with the blockchain um and to keep Pro processing blocks so from from this time uh while while elel was sying uh the CL could not propose a block could not vote uh because the uh the information um that is required to to to the validation duties uh validator duties was not was not there yet so it could not validate uh the uh payload D for instance so it can't can't vote uh on this payload unless it is fully validated by y so it's sying uh the semantics of thinking is kind of like a very undefined state where it's not uh it's it's not known whether the payLo in question in this case payLo D is valid and in addition it also not known uh uh the the the parent the parent block the ancestors of this pay are also uh not known to to the E and it is undefined whether this uh information can be pulled off from the network so El will just attempt to do this will try to pull this off um and uh but it can be the case in the edge case scenario where these blocks are um are unavailable and in this case the um El will you know will be syncing until the CL points out to some available chain and uh this how the situation would resolve so we have to uh we have to add this status to for E to catch up uh with the head of the chain uh once the El misses some data um to import a payload that is requested to get imported to validate it um yeah so this housing uh syncing status appears um in the engine API so we have like valid inv valid and syncing so far we did not cover like invalid case but obviously if uh if some pay lot is invalid and yeah the E will discard the invalid payload and c will discard it as well and never um and never import anything um any descendant of that payLo off yeah so here is um yeah let's talk about one of the edge cases for the syncing so let's consider this uh case that we we had before so we have e misses Block B and Block C it receives block D um and then the CL uh receives uh block e and also s calls the new payload with with the payload e um but uh at this point in time El keeps validating as I mentioned before syn process is happening asynchronously so El keeps validating and for E it appears that Block B is invalid so what should uh the question is what should El return in this case if it simply returns invalid uh CL will not know which one is invalid in this case so it will likely say it will likely okay so I send the CL would could like conclude that the payload e was sent and Y returned invalid so it means that payload e is invalid but in this case it's it's uh yeah it is the ancestor of payot is invalid which is B so uh and here is kind of the question to the audience uh do you know or how do do you maybe you already know how it's handled how this situation is handled anine API or if not but how would you handle this this case what would you do I'll just take a break take a bit of break yeah no we actually have the entire we have the payload yes and we have a payload hash if yeah so we have yeah that's that's it so yeah that's that's a yeah that's how it how it works yeah thanks for this the right answer cool yeah so what what's send in response uh um obviously status invalid and uh the El sends the latest valid hash which will be a so it's like which gives us the the required information so uh in this chain in this chain CL will see that the latest valid hash is a so it will conclude that block uh B in this chain is in so will invalidate all consensus layer blocks all Beacon blocks uh starting from Block B so that what it does and never gets back to this chain so this is one of the edge cases and this is what this is where we add more this is where our payload status becomes uh uh gets a more bits of information that is that are coming from E so and this Edge case was not obvious from you know when we were like uh discussing and designing this thing so it appeared uh some some time into this process and we had to uh and we decided to use this solution okay syncing so the sync process is kind of from the engine API perspective uh is kind of cover it to summarize we have a syn in status uh which has a which actually means that does not have enough information to say whether this payout is valid or not and it does not also know whether the actually in the uh and it may not know whether there is enough uh data in the network like whether there is a parent block available um the parent the parent block of this spil out is available in the network so this kind of like quite undefined state which e will uh recover from on its own with the information from CL side so CL will keep feding payloads uh to to e and Y will um resolve this um resolve this lack of data and this all overall this process called optimistic sync and optimistic means that CL keeps sending uh payloads to e to El without knowing whether the parent of this the parent payot is valid and yeah keeps doing it to let El sync uh with the network and this optimistic sync is completely different topic uh yeah so questions um actually where I notify new payload is basically the new payload code um and uh in this back I guess in this back it's not uh the latest valid hasch is not handled this case is only handled by um by real consens clients because this PC assumes that uh we are in the loog step mode so sying is is never returned um um because syncing is the uh specific status for of the engine API uh and uh CL spack is agnostic to the communication Channel between CL and El so CL SPAC uh is designed in a way that elel can be a part of Cl client so they can leave on the on the in the same binary so they don't need this uh engine Epi Communication channel to communicate so this why this CL would miss this latest valid hash because it's like where because just basically specific to the engine API stuff yeah while we were at the last example you said that the ex uh because of some reasons the execution client might have been left behind and the consensus client will keep sending new data like it won't it won't wait for the execution line C to keep thinking so like what are the ways in which execution client execution layer client can receive that data which it missed uh during that inactivity phase uh how will it ever poope up uh is the question uh how the El can receive this data in other way than the given by CL or is the question what is the other situation where El can uh Miss data uh since since CL will keep sending new blocks and uh what are the therefore what are the ways in which El can catch up to the blocks can catch up to the blocks which which it missed during the inactivity phase like from where can the E client query those BLS like I see what you mean yeah yeah yeah I get the question so it gets it from the the def P2P from the P2P from the e P2P it has it can request blocks it can request State um so it depends on the situation yeah so it can get it from the P2P Network the Alp Network and here a little bit Yeah to expand on this there can be two situations the first one is sying from scratch so we have a started a node and it's just you know the state is empty and in this case the E will use the state sync so it will pull the state uh from the network um to like most of Y will do this um and uh yeah in this case they will just you know they will need the information from from CL side what is the head what is the current head so CL will need to go uh AE to strike to the Head uh and then you will be able to sync to do to to run the state sync the other case is uh what we have uh described in the on the slide what we had on the slide so some oage happened and in this case to feel the gaps to F the Gap yell will we we'll pull the blocks we'll just pull blocks blocks from from and will fully execute blocks and yeah c will keep fitting it with the new head but in this case uh um the head the new head is not that important for for El to catch up yeah I see um so why would the be unreliable to to get this information so so the E is RI uh so yeah I don't know what's this question is about so whether it's about CL trust in El or or uh what what's this about why why would the be unreliable to do this to handle this part why do you think so okay so yeah so uh cl cl has the the consensus information so CL knows what validators has voted on what what's block is finalized so this consensus part assumes that all those validators who voted we have an honest assumption here they haven't exe executed a block and if CL just follows these consensus bits of data and runs the consensus protocol it it knows that the it can assume uh that the what CL observed as the C of canonical chain has been validated by many uh many others and it is sayfe to uh it is safe to communicate this information to El and ask el to actually request this data and yeah rely on E that the this data will be requested and validated and this data actually with the with a high probability are available um in the network because otherwise why would the majority of validators vote um on some block oh yeah yeah so these rewards will happen and it's fine it's totally fine it's handled by and it's handled by CL yeah it's it's like you know if uh if while the E experienced aage uh the CL switch to another Fork um it will just say that okay this is the head to to Y this is the head you should catch up with this head pull off the required blocks pull off the the the blocks that you miss and execute them okay um so let's let's move on another bit of uh uh of of the client design uh that is reflected in the agent API is basically the State Management part so there are two approaches to the State Management which different El clients use uh the first one is which I called multiversion so um the multiversion State Management keep multiple versions of of the State uh and uh and those versions are kept up to a certain depth of a block in the block tree usually clients use 128 block blocks so if uh say a block uh uh block is 1,000 1,000 blocks behind some block is 1,000 uh depth uh has 1,000 depth which means that it 1,000 blocks behind current hat uh this state will be pruned so this state will not be available uh for this block but all that within some boundary within 128 blocks uh this will will be um around uh in the state database and uh these type of clients I would say they are more classic ones uh um like G and nether mind and Basu um yeah they they can actually whatever block uh comes from whatever Fork uh so we can because as we previously seen we can have reorgs we can have uh multiple uh Forks a block tree so this client usually can instantly execute blocks on any Fork of the block tree so basically where uh the the examples that we had before where new pay load um matter is called and it returns valid syn in synchronous fashion this was about these clients mostly so they can execute blocks on any uh uh Fork instantly and respond with the full status which is valid or invalid the other type of clients uh the other approach to State management management is single version approach this is to only keep the um the one State uh which is the post state of the head of canonical chain and this this is quite novel approach and uh yeah it's reasonable because uh um it's yeah it's quite efficient um in terms of space um and uh quite Works quite good in the case of reworks uh this first this approach first used in Aragon and it's also used in W uh so it's actually used in all ericon based U State Management clients and uh what what specific about this type of clients is that they cannot uh they they can only execute blocks um on a chain when it becomes canonical so it means that uh consider the situation where the the child of the canonical of the head of canonical chain is coming so this this client will be able to execute this block instantly because it has um it has the the post state of the head but if uh uh if the block from the other Fork is coming to this client it will not be able to instantly uh execute this block and respond with a meaningful uh valid or invalid status so it will um uh it will it will handle it a bit different um so if if the if the chain from which this block has came uh will become canonical only then this client this type of client will execute this uh block and this is uh yeah uh this is like yeah so this is what I've been like talking about so this is like multiversion it um client handled this situation so yeah the this is the example from the same example that we had in the on the reor slide so block D is coming um the block uh the block the payload D requires the uh Post State of uh pay B to be validated um to be executed and this state is available in the multiversion case in the multi verion design clients uh it it's been executed uh the status is uh turned immediately in a synchronous fashion and then yeah from Choice updated happens so CL knows knows that this payload is valid and cl can actually switch the hat to to to the blog D to the corresponding blog D yeah in a single version so what happens here uh the C is the hat and uh the post state of Block B is not available so block D is coming what uh what happens here is like yeah we need to decide what we will do uh in this case and basically the decision uh is to to introduce a new status which is accepted and the accepted status the semantics of the accepted status is um uh so the payloads parent is known and the entire chain of of pay Lots ancestors are known the block has and all these uh thing all these bits of information um that uh are validated without executing a payload uh they are also kind of valid this information is valid for the entire chain but the payload execution status is unknown so this this is what this status means um and C clients and from the perspective of Cal client this status is kind of like sying so if if you see that the block D is accepted you can uh um you obviously uh yeah can cannot uh uh vote on this block and uh whatever else um and uh yeah so what what happens next so we have these block D is accepted right uh so we don't know anything about like uh whether it's transactions are valid or not so where where is the execution of uh this block is valid or not so when the payload execution happens actually is uh when the CL uh calls the folk Choice updated method so the CL decides okay so there is the some accepted uh method d uh accepted payLo D accepted block D and uh CL doesn't know whether it's safe to switch to this uh to to this block as the head of canonical chain but CL does this uh kind of optimistically and uh the F Choice updated in this case uh will trigger the block execution so the block D will be executed and uh this type of clients like Aron will use uh reverse State diffs to obtain uh the blog B uh the payload B Post State and apply uh the payload D on top of it so and in this case the fure is updated uh uh for this case is equipped with the the payload validation status so uh in this case if if the payload is valid uh the CL will switch the hat but also CL will CL needs to handle the case where the payload is invalid so it will not switch the head it will just invalidate this block and switch back to Block C in this case um yeah so this situation also has an edge case which is similar uh to the sying uh Edge case where historical block was invalid and uh yeah so we consider this uh chain of blocks DF and uh actually they were accepted and uh but in fact D is valid has D execution is valid but e execution is invalid and in this case when we use the same so uh we use the same um status we in this case where for Choice updated happens um um yeah it will the El will return uh the status invalid and will return L AS Val hash so this is uh how the this actually U um how this situation is handled very similar also uh yeah to to finish uh this part uh they can be the edge case and the spec allows for El clients to uh behave uh this way uh to to actually return sying When the El client knows that there is a long very long chain of accepted payloads and it will take a lot of time to executed it can it may return syncing so and yeah and uh once the forur is updated will be called again it it may return valid or you know invalid so um so the this actually means that the fork Choice updated response has the full payload uh validity status as the new blog um and this uh and and this uh this is required to handle uh different uh clients different e client architectures which are different with respect to the State Management okay so yeah g and B and Ne mind they use yeah I think that the clients now uh kind of Y clients uh um like G and you know multiversion clients they also have a reverse dat divs to do reor deeper than these um these uh 128 blocks um so they some borrowed some architecture from you know architecture solutions from from single version client which is great awesome um yeah r also uh is a single version yeah this just my my like you know separation so I don't know how they call call this Concepts themselves but yeah they are similar to Aron as far as I as I know okay so uh yeah if no more questions let's just do a summary um so the engine API uh allows for a separation of concerns between CL and DL um it allows to not bring kak RP and other stuff and transaction en code to to the to the CL side uh it also handles the payload out validation like transaction execution so it has a corresponding statuses for that and handles various such cases um engine API also H handles the situation where El needs to pull data from the network to keep validating the payload um that is requested by CL so there are special statuses there is a special status for this which is syncing um and cl needs to adhere to this status and not doing any performing any validation duty while El is in syncing is in sync uh so one of the core one of the core principles is kind of like for this API since this API is like very specific and uh is very important and only the critical path between CL and D on this for cl and DL communication uh we try to keep it simple and minimalistic as it is as far as possible and uh add things to this API only when they are really necessary um and yeah so um yeah also it has to this API has to support different State Management approach and uh yeah so this is a like the building blocks like the rationale behind uh what we have today so behind all these statuses and uh um and all the bits of information that c andl communicates uh with so and yeah what's what's what I haven't covered here uh is the um about the engine API that you can learn yourself from the spec it has version in so every meod has own version this is basically how we do hard Forks uh and where the semantics of the method is changing or semantics or the data structure this method operates with is changing uh the new version is introduced uh there is a bit of security uh it uses like if if say uh execution layer client runs on a separate MCH machine it uses GWT tokens for authentication so for basic security stuff uh also engine Epi has some auxiliary methods apart from uh from the core uh things and uh here here are some methods outlin here uh so maybe worst saying about payload bodies U this is done for C can of FL payload bodies transactions for instance and keep uh storing the only the payload headers uh this is done for the duplication purposes because the transactions uh this this information uh is uh stored on the El side and this information actually um consumes a lot of space so it is much more optimal to um to request payload out bodies from from E upon demand um also there are get blobs which is the optimization for uh for blob propagation there is a client version which Returns the L client ID and yeah exchange capabilities something that is used by CL clients and El clients to to learn about uh which meod versions they both support yeah so some improvements and some uh enhancements to the um engine Epi that we have today um that I would like probably to highlight here so some some C clients run block cash and other preliminary validations that we mentioned on on themselves on on their own so they only communicate with El to validate transaction execution uh this is done for optim optimization during the sync process uh Nimbus has a prototype client which doesn't use syncing so they basically uh um ask they have a St status method to ask elel about what is the most recent block that you are aware of and uh they roll back in their CL client to start syncing from from this block so syncing basically status is kind of like not used much uh in this in this case uh but that's a prototype and I think it's a it's a interesting uh idea and and step towards interesting concept of uh getting rid of El blockchain data um and uh use El just for State Management and transaction execution um so but uh I think this concept is is uh pretty um we are pretty far away from it because uh mainly because the the um blockchain data consumers the ethereum blockchain data consumers they use Json rcpi which is exposed by elel and mainly because of that El needs to to keep the blockchain data the AL blockchain data on their side so should we do this should we deprecate the L blockchain data we would need to uh do something uh about the API and probably uh switch to the beacon API extended with the user functions user uh user interface so um which which is quite a big big challenge uh I think um yeah so so uh actually uh there is a cortosis tool that allows you to run uh if you want to try the and look how the engine Epi calls look like in a live uh in a life in in the runtime so in a live client you can use cortosis uh here is the um tip dive of by e panda Ops Team on how to run an ethereum uh devet on your local machine and uh this guide also mentions the RPC snooper tool which is basically uh the man in the middle Tool uh that uh uh that tracks the engine API and other RPC calls between CL and DL clients uh so if you want to look at this and do this as the your your um kind of like um homework exercise yeah that'd be great um so this are the useful links and thank you very much um yes there are references here yeah thank you for um being with me on this session and if you have any questions please fire away happy to answer them [Applause] yeah just quick question on um like future improvements so of course we'll have things like Burl which we'll be trying to send uh cruce back to consensus Slayer and uh I'm just curious if the same flow will be um for engine API like four Choice updated and then get payload V to and just like maybe the payloads are going to be what's going to change with those types of uh future upgrades yeah definitely so in this case we would not need syncing right so uh we would kind of like the sync would not be would be removed from the critical path of validating the payload because the payload itself will have all the information required to run to execute transactions so this would be a great step towards you know um deprecating syncing and simplifying the whole communication between CL and DL nice looking forward yeah me too if anyone will will have any questions uh after and uh during their work about the engine Epi you know uh feel free to find me on Discord and ask questions and we I'm always happy to help yeah you you you can use yeah you can you can you can use cortosis uh to uh sorry um yeah okay um yeah you can use curtois too actually in this RPC snooper uh to take a look at how it works in practice so how these uh methods are called are being called by CL and responded by I think it's it's going to be a very interesting exercise to do this it it's going to it should be pretty straightforward uh so you just basically um run the cortosis um yeah just using this guide and uh and in one of the configs you set this uh snooper Tool uh to like just enable this tool and yeah it will it will drop logs [Music] um so you can see them the communication yeah on really um oh yeah that's a good question I I'm not aware that was affected anyhow um and I'm not aware about you know um some specific cases for for this part um um you know of of the client uh but this this uh difference between these two type of clients is kind of some something that is given and uh that is happening not only uh in the in the in the cases like holeski but sorry holeski and in other cases like it can happen on any test net and devet it's like a regular situation and uh to specifically to hes I have I am not aware of a very deep freeor of a huge depth where these um kind of you know uh would would start matter a lot like where we have like a very long chain that I know like a thousand of blocks and uh we re walk to that thousand of blocks and uh the like Aragon R had to execute those uh blocks you know instantly and you know yeah so I actually not aware I'm not sure that any kind of this R happened on holiday they were RS but they were like in a meaningful distance like in a manageable distance yeah if um the consensus layer will try to do get payload V2 and the execution layer isn't actually done like building the payload does it just respond back that uh I'm curiously if it sends back a status or will just wait till the payload is built and then actually send it no matter how long it takes or like a timeout for example just curious if that's like a failure mechanism or something uh yeah so if there is no such payload Bild process there will be error but if there is the payload build process it always initialized with like empty payload so there is all the time something to return in response and eel yeah it depends on El how do they do this but let's say that there is some time out like aund of milliseconds um after which the payload the the the payload that has been built before is replaced with a new one and uh yeah and whenever I get payload is called even though the new payload is being built like a new version of payload is being built there is something to return and this is returned and the payLo Bill process is stopped this happens something like that got it yeah yeah just curious what would be like the most common reason why uh you'll send back a payload statuses invalid that you see the most curious oh the most one interesting it could be a Mal for Block hash for instance or basically the yeah the most common one yeah good question can be anything like yeah the M forign Block hash or you know invalid block hash or something invalid or you know transaction execution is is invalid I would not say that something is more common than the other cool and I think actually this happens yeah it happens from time to time uh on devs and on testnets and sometimes it happens uh uh it also yeah but I'm not sure if it common to main that honestly you know there are CL blocks that are invalid uh you know but not sure about payloads sometimes you know happens that some Builder build a block you know um which is does not pass some basic validation some basic sales stuff cool we are right at the time so yeah awesome thank you so much again uh yeah we learned a lot today uh I really appreciate you uh coming here and and covering the engine API M uh it was really great yeah definitely learned a lot and please everyone uh take home the exercise take home the uh uh the uh crosis uh exercise to to try to run uh the client pair and uh see see how the API actually behaves live yeah uh so uh hopefully you can learn some more from this as well very awesome okay yeah cool um so thanks everyone again thank you so much for joining can listening to mle and again thank you so appreciate it was really great um yeah thanks a lot for having me here um um and to answer the last question like there is no engine Epi team really um so it it is maintained by you know by developers yeah so it's maintained by many people but there is no dedicated team okay thanks everyone