The Merge: Perspective of the Execution Layer | Merge & Scalability Summit

[Music] [Applause] [Music] next up is marius and mario's going to be talking about the merge but the perspective from the execution layer so without further ado let's welcome mars hello everyone what a nice discussion um i didn't really prepare that good so uh i hope that i can deliver something after this from my perspective i think it's very important to to have this client diversity uh especially on the execution layer and we're we're always trying to promote it always trying to build tools and at least get the other execution clients on the on the same like amount of testing that we do in in in geth and so yeah it's i'm i'm i'm hopeful about the future all right let's start my name is marius i joined the ethereum foundation uh one and a half years ago working on the gas client which is right now the biggest client on on ethereum and uh so today i'm going to talk about the merge from the execution layer perspective first of all what's an execution layer client uh i already said said it it's uh it's geth or or nethermind bisu aerigon and well it used to be open ethereum not anymore and yeah so those are the clients that currently run the network um and they have a mining consensus module built in which basically does the verification of the proof of work and during the merge and and afterwards we're going to [Music] take out the this this module and replace it uh with a consensus layer client um so uh the consensus layer client is going to follow the beacon chain and the execution layer client is going to follow the eth1 network um yeah and so we have an api between those two so the consensus layer client basically has to tell the the execution layer client what to do and some of the responsibilities of the execution layer client is to maintain state of the network this is all the accounts or the balances for everyone um the all the smart contracts smart contract code um all the states in the smart contract so if you i don't know if you store your mft then the the the the data that you need for your nft is stored in this stage and the state try which is basically used to prove um that that all the nodes have the same state and we also need to maintain the historical blocks and we need to provide access for both both of them two nodes that just joined the network so if you join the network and you don't have any state you will get the historical blocks from from all the other nodes they send it to you and then you can either execute them one by one but this takes a long time or you just download the state and then only verify that that the state corresponds to the newest block that you downloaded from your peers and this is also going to be something that we will still maintain after the merge so um the like the this uh sending and receiving of of the state and the historical data is still the responsibility of the execution layer we also store and distribute the transactions so if you send a transaction you typically as a user you use meta mask and meta mask then talks to a node either your own node or a node by a run by inferior and they will then like send the transaction distribute the transactions throughout the network and it will create and execute the payloads so basically um once the beacon chain says that we are the ones responsible to create a new block um the consensus layer asks us hey hey execution layer we want a new block so you take all the transactions that you currently have you sort them and then you pick out the best 200 transactions uh execute those um put it in a block and then return this block to the consensus layer the consensus layer will then take this block send it throughout the network [Music] first seal it so like sign that this is the block that that that is valid and send it throughout the network yeah as i previously said we have to provide an api for the consensus layout clients um to to to do this interaction with us and we also provide the json rpc api endpoints so those are basically things like eth underscore send transaction or ethercall if estimate guess all these things that are used by wallets metamask or applications to basically interact with ethereum in in the larger sense and these functionality will still be retained by the execution layer so this will be provided by us um yeah so a bit about the design of the json rpc api this is specifically the engine api so uh in the top right we have the consensus layer client which basically tells the execution layer client what to do and this this arrow is basically this api that i'm going to describe right now we have the prepare payload method that starts the preparation payload preparation process so basically give me a new block take the transactions that you have in your node and execute them and return me a valid block and the get payload and the reason that those are two different methods is because you you want to prepare you want to like give the execution layer a longer time to prepare payload for example if you want to do reshuffling of transactions uh looking for mev rewards whatever you have two calls two different calls and then you have the execute payload call which so whenever whenever a consensus layer client gets a new block from uh from the other nodes in the consensus layer network so um it's that is like one one of the one of the things that's different between now and after the merge now the execution layer clients will distribute the blocks and so if a new block is mined then this node will send the newly mined block throughout the network this is not going to be the case anymore now it will be that the consensus layer client will will distribute the block and the execution layer client will only distribute historical states historical blocks and so once the consensus layer client receives a block from the network it will call execute payload with the payload within it within the peak check block and that returns valid if the if the payload was executed correctly and then we have another method called consensus validated this is a method that might not be um so so this this engine api is pretty new um and it's still uh under development it might change a bit in the future and one thing that might that we might delete is the consensus validated rpc call because that is not really used by the execution layer basically it just tells you that a block was valid regarding the beacon chain specification the idea behind it was that once you once the consensus layer got a block it will call execute payload and while the execution layer is executing the payload the consensus layer will verify the signatures and once the signature on it is verified it will call consensus validated might might be something that we won't do in the future and the last method is fortress updated which basically just notifies the execution layer client of the current tab and the last finalized ahead last time block um so with the x with the execute payload you just execute the payload but you basically you don't move the chain to to that head with uh fractures updated you will you will move the move the set the chain head and this means this is now the current head the the most recent block and if we don't have this block and you say hey this is the block that was that was that you need now then we're going to start synchronizing from the other nodes in the network um yeah so a bit about the merge itself so right now we are in this part left here we have the proof of work chain which is chugging along and we have the beacon chain which is also chugging along and the the condition for the merge is the total difficulty so we have the sorry the total terminal difficulty um so every block has a difficulty which is derived from the amount of work that you have to do for for this block in proof of work if you sum all of these difficulties up from from the blocks you arrive at the total difficulty and the total terminal difficulty is basically a parameter in the consensus in the execution layer clients that says once this total difficulty turtle terminal difficulty is is exceeded we will stop the stop the proof of work chain and go into the proof of stake chain and so yeah and after after this is the merge point and after that the blocks um are embedded into the beacon chain blocks so the the execution layer blocks are embedded into the into the shape blocks um yeah a bit about the switch um our clients of course need to stay in sync with the proof of work network up until the point of the merge um and we also already need to provide all the payload calls so execute payload uh create payload get payload because we don't want we don't know if we might be the one client that gets to propose the first beacon chain block and on the first fructose updated call we know we check if the total terminal difficulty is reached and if the pad block is hash is valid and if so we switch to proof of stake mode and this means we also disable prop block propagation as i said before we don't send out the the the new blocks anymore only the historical blocks and uh we set the chain head to the new proof-of-stake block um yeah one one uh thing that i wanted to talk about is the reverse header sync um this is something that that's uh that's new uh with uh with with the merge and basically uh it's about the way um that we synchronize uh the network um it used to be so if you join the network you only have the genesis block uh so it used to be that you will just ask your peers about uh all the blocks that they have and you will you will start from the genesis block and then synchronize to the next block and you will always and and there are sibling blocks or it can happen that there are sibling blocks that are on the same block height different blocks on the same blockade and you will always take the one with the with a higher total difficulty so you will always take the chain with the highest total difficulty and so you go basically you start at the genesis you go forward in time now with the proof of stake chain it's um and like creating these sibling blocks require solving the proof of work and this is something that's hard and in proof-of-stake creating this sibling blocks is pretty easy if you don't finalize them but uh yeah the the idea is um we need someone to tell us what's the actual hat and this is done by the beacon chain so basically the beacon chain synchronizes and then um after the merge tells us hey this is the new head um here find the way back to the genesis and we can look up this we have this this this header and we know okay we have the in the header is the parent hash so we look up in the network which header has this parent hash and then we we find this this header and in this one we look up the parent hash and so on and so on until the genesis blocks so basically we synchronize the network from the news block back to genesis and this is the reverse header thing so a bit about the interrupt um this is a picture uh photoshop by by devlin from the previous panel by the way um yeah we started uh implementing an initial version of all of this it's uh built on on guillaume's catalyst uh guillaume is going to give the talk after after me and he worked a lot on all of this uh during during the rayanism hackathon um and laid the foundation for basically what i'm what i'm talking about today uh peter also worked on the reverse header sync and we already managed to test um all of this with four out of the five consensus layer clients um yeah what was one one one small project that i wanted to show regarding regarding the execution layer is much faster it's a new project that i started on the last day of the interrupt because i was so bored and it basically creates random inputs to the merge api and it can be used for differential fuzzing between different implementations so again it it helps we're always trying to build tools to um that cannot only be used by gas but also can be used by by other clients to make sure that they are they receive a a comparable level of of testing uh to us um it does things like execute payload and fork just update it and verify the current heads so in like in random operations and um you can find the code at my github some next steps we have to clean up all the changes we did during the interrupt of course all of them are a bit a bit hacky right now we have to refactor the downloader to allow for this reverse header sync we have to work a bit on the miner and block production and also refactor some of the existing json rpc apis because they might not work with the way that that pos is done after the merge and then more test nets testing testing testing um it doesn't like it it's for us it's really important um we don't want to start start the merge procedure when we finish the code but we need enough time to test it because this is the ethereum grew so big it's a it's a billion dollar network and we don't want to like uh crash it so we want to be as conservative as possible with this even if it takes a bit longer and yeah you can also join that like we have a long-running test net there was one started in greece at the interop we deprecated this now and we started a new one or peritour started a new one and yeah that's basically it i do have some i i collected some some q and a's from twitter um already but kartik if you have other questions from the uh from the audience we can also absolutely i think i know i saw that tweet and the thread and there were so many awesome questions that came in so i think you should definitely answer a lot of them one question i'll add to this list is a question from danny ryan which is uh what are you most concerned about from an el client perspective as in what keeps you up at night there easy stuff so uh it's it's uh uh not much keeps keeps me up at night anymore um after uh like one and a half years in the in the guest team i i think i've seen i've seen a lot uh we had issues uh in gas we had issues in in go in the language itself in the standard library um i'm pretty confident in in our ability to adapt and our in our ability to if there's an issue we can we can find it and fix it rather quickly the last few consensus issues were found in in in a matter of like half an hour to an hour or something we have a cool great suit of tools for uh for testing the evm stuff um what what really keeps what what the only thing that i would say what keeps me up at night is that we might finalize something that is objectively wrong and that we might have to break finalization and uh i think that would be really really bad it would be bad for for for ethereum it would be basic yeah it would be really bad and this is the only thing that that i that i really worry about um and i hope things like um proxies to run a validator off of multiple execution layer clients um is something that that could help there that makes a lot of sense uh there's another question that came in just now from uh from trent the question is uh can you tell us more about the minority project peter teased about earlier just give us a little context and you can jump right into your q a yeah i'm not i'm not sure if if i should talk about it too much basically i think the the idea was born in increase that you can run multiple execution layer clients for one consensus layer client or one beacon chain client or maybe even run multiple beacon chain clients with multi multiple consensus layer clients with multiple execution layer clients and multiplex between them and then take like a two out of three majority vote and this is something that he's very interested in in working on well trent is a little bit disappointed but um we can maybe have you go quickly on some of your questions um yeah so uh uh i think um hudson asked whether it was more difficult to fork the code after the merge um it might it's a bit more difficult i think um but uh shortly after the merge we will still have to retain all the functionality from pre-merge and so uh yeah there's not a big difference uh once we are comfortable in um in uh in post merch land uh we should really find a name for that i don't want to say east 2 but yeah in proof of stake land then we will start deprecating we might start deprecating some of the features in in geth the east balances will be maintained on the on the execution layer so the execution layer holds all the information of the current state um will execution layer and consensus layer share the same process and storage they won't they will at least for the merge and uh probably a long time afterwards they will reside in in separate processes that talk to each other via the standardized engine api they will have different storages they will have different storage formats and and i don't think it makes sense to to unify those um which layer will propagate the blocks uh the consensus layer will now propagate the the blocks the beacon chain blocks which contain in them the execution layup the execution payload um how is the transition triggered um as i said it's it's the terminal total difficulty um if this is exceeded the the block that first exceeds the total terminal difficulty uh will be the the last proof of work uh what's changing for users do you need to upgrade your nodes hopefully for the average user that oh it just holds eve there's uh not much impact you don't you don't need to upgrade your wallet or whatever you will need to upgrade your node your guest node and you will also need to run a consensus layer node or maybe in the future a consensus layer light client that will feed all the blocks to your uh it's uh to your to your um execution layer node uh how does the block proposer collect the transaction fees um the uh the execution payload or the the assemble param parameters in the create payload has a field called fee recipient which basically it's the same thing as we used to have with the coin base address um so the uh the block proposal uh sends the that's the how it is right now it might change with the proposal separation in the future but the way it is right now the block proposer can send can specify the where the fees should go and those will be paid out instantaneously once the block is mined and the last one is something that's still up for debate yeah and just really quickly we have a test net up and running if you go to pythos minus explorer.ethdevops.io and you can see that there's a lot of clients client combinations all currently always get the other have some problems apparently to run this to run this test network and you can join it from home to test all of this out which is really cool so go do that thank you very much awesome thank you so much marius uh this is a great overview on what's happening with the execution layer and if you have more questions i'm sure maurice will go back on the chat and answer them directly [Music] [Applause] [Music]