Understanding EIP-7002 and EIP-6110 | Devcon SEA

[Music] [Music] it it is right okay so yeah I'm Lucas and I've got Stefan here with me um our talk was originally designed to be two talks but do some scheding things we had to merge them together so well we'll do our best to make sure we go through the content and everyone understands everything so yeah I'll start with my part and then we're going to have Stefan thank you St thank you okay so we're going to start with EIP 70002 execution layer triggerable withdrawals before it was named execution layer triggerable exits but there are some updates that um made we renamed the zip before talking about the EIP I want to go through a little bit of a context here so I'm assuming that everyone is aware that in ethereum we have validators and they are staking 32 e and then they performing the duties like voting at the U voting for new blocks with at the stations proposing new blocks and things like that and well when you're creating a validator maybe everyone knows that but we have two sets of credentials you have your validator key which is associated with your validator public key which is used for signing your blocks signing your attestations and everything and you have your withdraw uh key which is kind of represents the uh ownership of the state amount of of of E um another concept is solo staking versus delegated staking so this is kind of a different thing like staking is staking but uh I think solo staking will be uh kind of the most basic uh thing when you think about staking you know you have your laptop you create a validator you have the validator key you have your withdraw key so you own kind of everything and when it comes to delegate staking there is like a bunch of different uh Arrangements you have custodial non-custodial but for this exercise that's just assume that you own the withdrawal key someone else owns the validator key because they're running your node for you but they do need the key because they're going to be signing the the stations and everything so they need the key so that let's just do with that okay another thing before we jump into the EIP uh I want to touch on voluntary exits so um voluntary exit since phase zero has been pretty much the same you if you want to exit validator you don't want a stake anymore you will uh send a volun assigned voluntary exit message but that message is signed with your validator key so you sign that message broadcast it through uh send it through the beon API it's going to be propagated in the network eventually included in a block and after some time your validator joins the exit Cube pretty straightforward uh however as you can see in the diagram here if you don't have the validator key you're kind of in trouble because you don't really have a way of accessing your valid dator and you need to kind of ring your operator hey could you please exit my validator for me well if they are you know nice people they will do it for you but you know it's kind of like a grief Tech Vector because technically the the node operator can um like not really do their best job uh when doing their decisions and everything and they have ways of like slowly chipping away your uh your uh steak which not great there are ways around this some other operators will give you a pre-sign exit message when you join the uh the system so you keep that message safe whenever you want to exit you already have the signed message and then you can exit this is a workaround because there are a lot of complications with this there's a lot of you know you need to keep that message safe you don't you're not 100% sure if that message is going to work and they have to have all the infrastructure around managing that message and everything so it's yeah it's kind of a heck well back to the problem that we were talking about we you can only exit your validator today with your validator key right and the solution is easy just allow both the validator key and the withdraw key to exit the validator yep it's it's pretty straightforward unfortunately implementing it it's not that easy um and that's pretty much the context and how we get to EIP 7002 so why it's not easy it's important to remember that when it comes to the consensus uh layer and the execution layer the consensus layer doesn't have like a complete view of what happens on the execution layer right so it's got like a limited amount of information that comes through that side I think a good example of this is you think about deposit processing stepan is going to be talking a little bit about about it later it's a complicated it's a complicated Mass you know it's a whole system keeps updating and fetching information it's not that easy so what we really need is we need a mechanism to create a message on the execution layer send that message all the way to the consensus layer but that message has to be authenticated with an account on the execution layer side but at the same time all the authorization happens on the consensus layer side because the consensus layer is the one that knows who's the validator what's the withdraw credential associated with that validator what's the balance and all this kind of stuff so that's the kind of the the thing that we're trying to solve here um and that's pretty much the idea with withdraw requests so it's a request that comes from the e goes to the CL and it's got um pretty much three uh pieces of information one is the source address which is supposed to be the address that you have set as withdraw credential on your validator the public key which is basically what is the validator you send you're sending this request to and the amount which is an interesting one so before we didn't have the amount so the amount was introduced because after EIP 7251 if you guys were here to listen to post talk on Max CB now it's possible for validators to have more than 32 e uh balance right so technically you can have a validator with like a th000 eth or something stake so we basically split the uh the withdraw into two different types of withdraw you can do a full withdraw which means I I want to withdraw every single way that I have staked which basically translate into an exit or I want to do a partial withdrawal which means well you know I have 100 E I want 50 back because I want to buy a new car or something so you do like a partial withdrawal you get it back into your uh account and then you can use the money and that's the we use the amount Feud for that so an amount equals zero means a full withdraw which can be a bit a bit weird to think about but and an amount uh greater than zero is it's like a partial withdraw I just want to withdraw part of my stake hopefully everything makes sense until now um and on this diagram I'm trying to capture uh how things have changed compared to the previous diagram so the way that we're creating this mechanism is basically now we're going to introduce this withdraw request smart contract on the execution layer side and that con has pretty much two uh two functional two functions so the first one is a function that the user is going to call to basically create a a request so when when the user wants to create a request I'm going to send send a transaction signing it with my withdraw key not the validator key and the Contra is going to look at it like oh okay that that that's cool someone's creating a withdraw request it's going to set that address as the source address on the request uh and I'm going to be on this request here we pass two pieces of information the validat public key and the amount eventually uh the execution client is going to call the contract and read uh the information for it read the request that are on the on the Queue the is on the contract State and send it over to the Bono to engine API and that's I'm not going to go in a lot of details of that because again not a lot of time but basically when whenever it's time to create a block and the beon node is going to receive those requests from the El uh some verification happens and everything and then the authorization part uh happens on the consensus side it's going to look at the request make sure that the source address so the account that is send in this transaction here matches the with credentials on the validator on the consensus side and um some other rules you know make sure that you exit you're creating a request for the right validator and everything cool so hopefully this makes a bit more sense uh one interesting thing uh to note here and that was actually probably like half of my original talk is that when you look at this uh this kind of Orange area here you can see that this mechanism for sending requests from E to CL can be quite useful for a bunch of different things and yep we did notice that and that's why we have um EIP 7685 which introduced this concept of uh execu um general purpose execution layer requests so now we already have all this mechanism for creating different types of requests for the next four Spectra we already have three types of requests we have withdrawals the ones that we were just talking about we have deposits the one that Stephan's going to talking about and if you were here for the previous talk consolidations it also happens through a execution layer request so um that was kind of the most interesting part of uh this uh system so yeah take a look into that because it's pretty cool uh before I finish I just want to go through a few uh caveats because you know there's no free lunch there's always something that you need to give away so the problem with uh withraw requests and kind of the execution requests in general is that but creating a successful transaction on the El side like creating a request doesn't guarantee that that request is going to be successfully processed on the consensus layer side I know it sounds a bit weird so it the the user experience is a bit clunky you kind of need to look at the consensus side make sure that everything works out create the request and that just kind of hope that nothing's going to change in this in between um hopefully it's not going to be too bad but it's it can it can happen and another interesting thing is if you currently have a validator and your validator has a contract address set as withdraw credentials um well things are going to be a bit bit more complicated uh for those of you who are familiar with the evm uh the contract that is creating the request is not looking at the transaction sender for authentication it's looking for the message caller so that means that if you are interacting with the request contract using a smart contract the smart contract address is going to be the one that's going to end up on the source address right so for this whole thing to work your validator withdraw credentials has to be the contract address not the add not the account that is sent in the transaction so again I'm sorry for you if you're in this situation um hopefully if you have upgradeable smart contract you can kind of get away with it you can use like delegate calls and do some very smart stuff to make it work uh that's not my expertise I'm not going to talk too much about it but there is a way for you uh but yeah just keep that in mind when you uh looking into this um oh yeah one important thing is that this does not replace voluntary exits voluntary exits are still the easiest way to exit your validator if you have the validator key you sign the message it's going to be broadcast to the network it doesn't cost you gas or anything there's no transactions involved so yeah yeah keep doing that if you can but this is basically like a way of kind of filling that Gap that we have on those scenarios where you don't have your your your validator key and quickly before I run out of time uh I just want to mention that withdraw requests uh different from withdrawals in the sense that if you guys remember capella that's when we introduced withdrawals a withdraw requests can eventually generate a withdraw when you're doing like a partial withdraw but they're not same thing just because yeah the terminology and things like that okay that was a lot hopefully enough for people to understand I'll leave it here and then I'll hand over to Stefan for his Mar thank you oh thank you how does that work just yeah next slide okay hello uh so I'm going to talk about EIP 6110 which is Supply validator deposits on chain and you may wonder what the CIP is about because validator deposits are already on chain but the keyword here is Supply so essentially the CIP changes how the deposits made to the deposit contract which sits on the execution layer how these deposits are supply to the consens Slayer where either a new validator is initially ized or an existing validator balance is topped up so I'm going to start by explaining briefly how the current deposit processing works and then I'll go over the depositing processing after this EIP which will be part of the next Fork yeah so current deposit processing uh basically a user submits a transaction containing deposit data to a deposit contract which is uh essentially 32 if and users usually do that via the staking launch pad and then there is this uh 8 hour delay where the consensus layer has to consider the state of the deposit contract and this has been designed to be 248 blocks uh when with proof of work blocks which are which were around 14 seconds and this was done to ensure that if there are any issues with if1 uh then uh essentially that wouldn't impact the beacon chain and 8 Hour was just it gives about enough wiggle room to ensure that any issues are fixed and then there is a voting which is a 64 EPO and it's kind of this is like a off-protocol consensus mechanism it was designed before the merge and basically it ensures that validators agree on the state on on the same view of the deposit contract which sits in the EO and before the merge basically the EO is driven by proof of work so there was no real connection between the execution layer and the consensus layer um and then this voting basically it finishes when at least half half number of the votes are the same and after that proposers include those deposits uh alongside the block and then all notes can verify these blocks and then uh a valid deposit basically either creates a new validator or it tops up the balance of an existing validator and this is a diagram of the current uh process so you can see this user he uh B basically does a deposit transaction use the stank launch p and then the important part here is basically you can see on the right the Bon note and it has this chunky if1 module which constantly psts the E via the Json RPC API and it does that 248 blocks uh constantly it POS it in order to build the merco tree which then can be used to produce proofs which are included alongside deposits uh and this is the current process which is still still ethereum works like that even though we have already migrated to proof of stake we still use this J an RPC and the way this the EAP 6110 works is it simplifies a lot basically the same deposit transaction is made uh but then the deposits come directly from the e via the engine API and they're included in blocks and then they process on finalization of the chain which is currently around 13 minutes and then the same flow the same it's again the same thing a valid deposit will are create new validator or top up an existing validator and the diagram now uh looks like this which is pretty much what Lucas showed you basically have the execution requests and now you get the deposit request over the engine API so whenever a proposer proposes a block they get the deposit requests and uh basically this whole E1 module which was quite chunky now it's no longer part of the Bon note um so this is the diagram and to quickly summarize the advantages of the EIP basically there is nowadays a delay of around 11.4 hours before your UH validator is added to the activation queue and this is basically the follow distance this 248 blocks which is around eight hours and then there's this voting of around uh 32 EPO which is 33.4 hours uh and now this is reduced to Just Around 13 minutes or two AO and another Advantage is the increased security because we no longer uh rely on this off protocol mechanism now we can just now we just inherit the security of the chain and uh also there is not a benefit because currently we have these deposit contract snapshots which basically are um a merket tree up to a certain point uh in in in time and we no longer need this because we no longer need to provide proofs because we're just uh getting the deposits from the engine API and one other benefit is that we no longer rely on the Json RPC API we only rely on the engine API and it's also we just no longer need that very Legacy Legacy and brittle part of the C clients code uh which is always good to delete stuff uh and one more slide I wanted to show I wanted to quickly show that this EAP is actually not is actually simple to uh Implement so if you're interested you can go over this link and see how we implement it we generally try to do small PR so it's just eight PRS but it's not big changes uh so if you ever want to check how ANP is implemented actually this is a good one to go over because it's quite simple um yeah and that's uh that's it pretty [Applause] much thank you thank you we're going to get to some some questions now um and again uh if you're new to uh seeing a talk today scan the QR code add your question and you can vote if there's one that's already there and you would like to see it answered just to make sure it gets answered and push to the top of the que um thank you thank you so we will start with why a valid request from the execution layer would be rejected on the consensus layer um I can probably take that one um it's it's hard to it's hard to go through all the different reasons why uh I think the best way of thinking about it is that I like to separate that the e is doing the authentication side of the uh request and the C is doing the authorization side of the request so I think the easiest example that I can think of uh for example for withdraw requests let's say that you create a request for someone else's valid dator right so the transaction is going to be successful the request is going to be added to the uh to the contract but when the cles that request is going to try to match the source address with the validator uh validator withdraw credentials it's going to say well well you don't really own that you can't really do that right so that's one of the reasons um yeah like there are other more specific rules that can but I think that's probably the easiest way to think about it the E doesn't really know the rule the business rules on the CL side in the same way that a can't really validate beforehand that that's the right uh validator so that's kind of part of the reason hopefully yeah that's it thank you and looks like we have another one for you right again so why do you think contract address as a withdrawal itial is a caveat um it's it's more like it's a more complicated thing because um there there are two problems with this one is that the currently the validator withdra credentials cannot be updated so once you I didn't really touch on the whole BLS credential side of things which is something that already was there before but the way that it works right now once you set your validator withdraw credentials to one address you can never change that address so so a few problems happens here the first one is as I mentioned if you have your valid dator credentials set to a contract address that is not upgradeable you're never going to be able to update that code to call the request contract so you you you're you're already kind of locked out from this mechanism straight away if you have an upgradable contract you can write some code to kind of get around it um so it's more like a kvat in terms of something that people need to get their heads around and make sure that they consider when they implementing because I think the natural thing to think is well I'm going to sign the transaction with this credential with this account sorry uh key and that's the one that's going to show up on the request but that that's why it's kind of a caveat thank you all right now for you um if EIP 6110 makes eth1 vote Legacy do we have to carry all eth1 voting fields and Logics in consensus layer even in post Electra yeah sure uh so there is a little bit of transition period when the when post electrod to transition to the new way because we still have to process deposits VI the old way for some time but after that is done we can pretty much remove all of the this Legacy code in uh in next releases after the fork thank you um is there a proof generation process to withdrawal similar to performing igen layer withdraws um unfortunately I'm not familiar with IG layer withdrawals process but there's no proof generation on this withdrawal um hopefully uh if I understand the question there's no Pro Generation Um what if a deposited request failed will users eth be refunded so when you deposit if to the smart contract there is technically no way a deposit request fails so if the deposit request fails that that means that there is like a consensus failure which yeah it wouldn't be refunded but it's a big issue all right I think we have time for one maybe two more um how resilient is the engine API comparing to Json RPC API yeah so the engine API basically drives the execution uh the consensus layer client drives the execution layer client via the engine API so it is very resilient the Json RPC API can uh it's not it's still very reliable but it is not uh critical so there could be some implementations in some Clans which are less reliable to the engine API which is very very critical awesome and we have just about 5 seconds left so probably not enough time to get to next question but if you'd like to come up to the speakers and ask them questions later they'll be sticking around for a little bit um so thank you very much let's have a big