EIP-7702: a technical deep dive by lightclient | Devcon SEA

[Music] [Music] hey good afternoon everybody uh so excited to get to Devcon started with you and to talk about this EIP 7702 before we get into the technical Deep dive I was just curious who saw this headline from coindesk this was how we introduced 7702 to the world 22 minutes of italic writing the pr for the EIP but it really started from this future of EA AA breakout call we were kind of having some deadlock with the wallet developers in the community and the client developers getting agreement about what exactly should happen with the Prague hard fork with respect to accounts abstraction and in this telegram group this AA Mafia telegram group that some of you are probably aware there was a bit of discussion with alic about what we need to do and right before the breakout room he had a breakthrough and he was scrambling to write the polar request for this EIP and ended up taking about 22 minutes to write this first proposal but that's only part of the story so obviously these ideas happened through many months and years beforehand and we've been working on 3074 for a couple years and these ideas are not new there's been commentary that maybe 7702 is being rushed to the main stage for ethereum but I don't really think this is the case this is something that's really encapsulating a bunch of ideas that we've had with 3074 over the years and now we finally found the right way to package it together to give the best interaction with wall developers client developers and generally what we want ethereum to look like in the future so with that said that's some prehistory for 7702 let's jump in into the actual technical details about how the CIP works I think most people in the room probably understand the motivation for the EAP so we can kind of skip over it but I do want to mention this bootstrapping phase because this is kind of something that is a big differentiator between the prehistory this 3074 history and the world with 7702 so with 3074 we had this idea that we wanted to make EAS as generic as possible and let them do any kind of execution that you can imagine so long as they provide a signature to make to authorize the execution with 772 we tried to take a bit of a step back and this was really the Breakthrough between 3074 and 772 we wanted to allow EAS to have the power that they deserve to have but we wanted to try and push users in a direction of using smart contract wallets and we felt that this was an important phase of bootstrapping the smart contract wallet Community where instead of having to choose is your app going to natively support EAS great uh or smart contract wallets great you get the opportunity to have a unified interface across both EAS and the smart contract wallets so how how can we do this how can we create this environment for users well if we recall this is what an account in ethereum looks like you have your Nots balance code and your storage route what we want to do is we want to take smart contract wallet code and we want to put it into the EA accounts how is this possible this is really what 7702 provides we're introducing a new transaction type the set code transaction type and the way the set code transaction type works is it's extremely similar to how the 1559 transaction type works with this additional authorization list element and inside the authorization list you have your authorization which is basically saying as an EA that you would authorize some code to live into your account in the authorization there's the four elements we have the chain ID the chain ID is just saying I authorize this account this address to act on behalf of my account on this chain the address is the address of the account which you're authorizing to act on your behalf what do we mean by this this is this idea called creation by template and it's a bit different than how you deploy contracts today on ethereum unlike the init code deployment that most of you are probably used to where you return the code that you want to exist in the account at the end of the init code you actually say just immediately what the Target that you would like to be put into the account is so instead of running this initial initialization phase you actually have the initialization via regular call later on in the transaction why do we do this a big reason is that we wanted to minimize the amount of call data from trying to migrate your eoa into a smart contract wallet and what we found is that you have to say what what Target code you want to execute in your account it's not as simple as it's not as simple as providing just a 20 bytes to because typically you have to provide the 20 bytes for where the template is going to live and then you need to have some setup code around this to X code copy the data bring it into your account return it from your nit code and we found that having this extra amount of data just moving bytes around ethereum was pretty much unnecessary and we wanted to focus on just providing the address which the code would be pulled from we also feel that this minimizes the chance that users are going to change their delegations regularly like I said this bootstrapping phase we think it's really important that we get users focused on using smart contract wallets and not trying to create different types of ux in ethereum where they have maybe ephemeral delegations that only last short periods of time now creation by template as I'm describing is basically saying take this address and put the code of that address into my account this doesn't quite work today because we have an EIP 3607 and what it says is that if you have code in your account it's not possible possible for you to originate transactions so we need a way to work around this and how do we do this this is basically the idea of what is going to go into your account so after you submit a 7702 transaction with your authorization you'll end up with a delegation designator into your account and this designator is a structured piece of bite code it's 23 bytes and it starts like this you have the first bite this EF bite this comes from the EIP 3541 and we had this in several hard Forks ago with the idea of creating a a special domain space of account code that users could not deploy to so today it's not possible to actually deploy a contract that starts with the bite EF and you might be familiar with why this EF bite came from originally we have this idea in the future to have the ethereum object format eof and this will create a new space for eof contracts to live where there's some been some validation done to the accounts beforehand what 7702 does is it builds on top of that idea and so it adds a few more discriminator bites to say this is a 772 delegation designator and at the end you have your target address the remaining 20 bytes so you can think of this pictorially as having a pointer in your account that says the code for my account should be loaded from another account and the other account that we're thinking of in this case would be some kind of smart contract wallet okay so that's the chain ID and address we've got the nons and signature the nons is just going to be the nons of your e EA and the signature will be a signature from your EA just providing replay protection and some authentication from your account that you actually do want to set uh a delegation to your account perfect I don't know if you guys can all read this in the back but let's dive a little bit deeper into exactly how 7702 Works uh we can think of this function process authorization as something that lives between checking that the transaction is valid and before the evm execution for your transaction happens what we do is for every authorization that exist in the authorization list we first check that the chain ID is either uh not equal to the chain ID of the chain or we verify the chain ID is not zero so there's an additional uh there's an additional opportunity for 7702 authorizations to say if the chain ID is zero it's valid on all chains similar to today with transaction signatures one thing that might be confusing about the way that we process the authorization list is you can notice that there's a continue here rather than raising an error or returning a fault the reason that we do this is that we're trying to avoid very complex interdependencies of transactions because the transaction type is relying on the nons of the EA you could imagine that you have a transaction that has many different EAS within its authorization list that could possibly invalidate many other transactions that are pending from those accounts so what we've done here is we've kind of tried to keep this the transaction validity simple focusing only on the overarching sender of the set transaction format the set transaction object rather than creating this dependency level and we feel that this avoids any kind of denial or service attacks that users might be able to come up with so after you verify your nons we'll recover the authority from the signature that's in the authorization uh if there's any kind of issue recovering it we continue on then we check the author the code for the authority here we check to see is there any code deployed in that account because if there's code deployed into the account we need to retain the property from EIP 36 uh 3607 where we don't allow the EA to originate a transaction so after we do that we also need to make sure that there's if there is code that the code is a delegation because we want users to be able to replace their delegation we don't want users to forever and always have a single delegation that they've chosen so you have this opportunity to update your delegation after that we do the nons verification and if it's correct bump the kns and then finally we actually make the delegation designator that you saw in the previous slide this is written into the account and now you have your delegation designator so all the operations will load the code that you're pointing to there's also an additional short circuiting mechanism here that we've done and instead of writing the actual zero address if you pass that as as an authorization address we will completely clear the delegation designator from your account and the reason that we do this is we found we want to allow users the opportunity to completely undo the delegation operation that way after you submit this operation it's basically impossible to tell that your EA was ever delegated to another account just to make users feel more comfortable with trying this new mechanism I want to try and wrap all these technical Concepts into maybe a more clear example so imagine you have some user and the user has a thought GE it would be super nice if I had a smart contract wallet because today my account just looks like this no code uh empty storage route I can't do any kind of interesting things like batch my transactions or have someone else pay for the gas for my transactions what they can do now with the pr hard Fork after 7702 is they can sign an authorization and this authorization will basically say on chain id1 the main net I would like to authorize the address a94 F to act on my behalf and they've signed the nons for replay protection and the signature that says that they authorize this thing what you'll notice is they have a balance of zero and as you saw before with the set code transaction we have to wrap the authorization to send it onto the chain but with an eth balance of zero they can't actually put this authorization on chain themselves so what they they need is they need another party to help them and so in this case they'll find some sort of bundler who can help them put their authorization on chain so they send the authorization to the bundler the bundler takes it puts it inside of a set code transaction and then the bundler can actually send it to the chain so this gets processed the user's account is updated their nons is bumped they still have a zero ether balance and the code is set so they have their delegation designator and you would probably think that we're done but if you remember when I mentioned you still have to initialize the account and it doesn't happen during the normal anck code what they now need to do is they need to call their account with some initialization data so they can do this uh with the same builder in the same transaction in a different transaction it's not some type of atomic operation they can do it at any point later on so they'll press this call data in and they'll basically say I want to set the owner of my smart contract wallet to maybe the same key as my eoa or a different key as my ea uh or maybe I want to delegate some different types of uh keys to my account I want to give it a pass key for my phone that can spend only $100 a day you have the opportunity to initialize however you want but you have to sign over this data because this is how you convince the account that you have the authority to uh to update what the owners are so this uh this call is sent to the the account it's processed and then we update the storage route and now the account has an owner they can continue using the bundler they can add some e to their account they can batch and do whatever kind of smart contract wallet operations that they would really like to do so we kind of glazed over what the gas costs of this thing are but since this is a technical Deep dive I do want to kind of go over them a little bit the intrinsic cost is extended to charge 255,000 gas per authorization in the authorization list and if the account is already already existing in the try we will refund 12,500 gas so you can really think of the cost of an authorization as 12,500 gas rather than 25,000 but the 25,000 gas comes from the uh creation of new account in the try this happens if you send ether to an account that doesn't exist you have to pay this 25,000 gas to create that account in the try you have to do it when you create an account uh so so what we do is we refund it if the account already exists but it is subject to the global refund C so if you get a 12,500 gas refund you have to spend 60,000 gas otherwise you're capped at the 20% if you spend if you need to get a refund of 2,500 gas you have to spend 120,000 gas to get the refund so it's not always an exactly 12,500 but we expect most of the time it will be the other gas cost to keep in mind is that we extend the convenience warming of an account to also include the target of your delegation so if you're sending a transaction to an account which has a 7702 delegation designation what we'll do is we'll also warm the account that the delegation is pointing to this is just a convenience warming it's an extension of sort of what has already existed what we don't extend is a convenience is during evm execution anytime you make a call to an account that has that delegation designation you do need to warm the account that you called and the account that the delegation is pointing to if either of them happen to be called so that's kind of the summary of the technical summary if there's anything to take away from this talk if it was kind of more high level or more low level than you expected in early 2025 you're going to be able to put smart contract wallet code into your account so the next things that are going to happen with 772 there's a ton of events this week around 7 702 and accounts substraction I think it would be amazing to continue collaborating with all the builders that are thinking about how to bring this to the user how to bring this to the masses and so experiment try some of these rolling Dev Nets that we have we have a rolling devet uh with the eth devops team throughout this week uh Ithaca has their experiment 00 one to try 7702 and check out what the application how the application standards are evolving there's a lot of opportunities right now to figure out a cohesive user experience for dap developers wall developers and users so that we can all use the same platform platform and not create a bunch of fragmentation around uh the new possibilities that exist in accounts so that's the technical Deep dive for 7702 happy to take any questions now testing thank you thank you we have a lot of questions so again if you'd like to vote for ones you want to see answered there are a bunch here and we will go from most voted down so we're going to start with why do we still need ERC 4337 after EIP 7702 yeah so I kind of pointed out to this in the diagram where you have this bundler that you're kind of sending the authorizations to and they're relaying some calls onto the chain 7702 doesn't describe how any of these things happen and this is like what 437 does in a lot of ways like it sort of describes how you get an operation from an account that has no gas and you re lay it on on chain in a safe way additionally with 7702 you always are going to have the EA key that controls the account and so if you think about it in terms of like a privilege privilege deescalation sense you always have a key that has complete control and if that's something that you don't feel is right for your security model if you feel like the only way to control your account needs to be with a multi signature you're going to have to use 4337 to do that awesome we will get on to the next one um sorry that didn't did that work on your side um we're going to start with uh can the chain ID be set to zero to authorize all chains yes the chain ID can be set to zero to authorize all chains but it is important to note that because the authorization has the nons in it it's not necessarily the case that every single chain has the exact same nons on it so you have to keep this in mind when you're thinking about creating a multi-chain authorization and then so EIP 7702 makes address space extensions obsolete I don't think so at all um the reason that we have the the the 7702 type bites in the delegation designator is it's it's 0 one0 so in the case that we in the future have address Bas extension it's extremely simple to just say we're going to bump the version of the 772 uh prefix bytes to say the next 32 bytes are the address rather than the next 20 bytes sorry I'm having a My Moment here but we'll start with I guess we're going to go just what's there so eoa revocation is required for post quantumness is it specified this isn't really specified by 7702 in any way we're kind of just extending the functionality of the quantum insecure eoas that exist um that's kind of future work to be done how does the signer of the O guarantees the initial initialization call as correct risk of front running I don't really see there as a I don't see that there's a lot of risk of front running if you have if you are authorizing to an account that is expecting this type of initialization in the diagram I was kind of trying to point to this and allude to this where you have a call and it's not a typical call because in the evm usually you use the message. sender as the authority of things but because in this type of Del in this type of initialization of account you might want to be Bund in the initialization through a bundler and you can't rely on message. sender so you have to verify the signature from the EA and this sort of gives you that trust to initialize the account in a way that can't be front run by someone else because only you can control the private key that you're that you're creating the delegation for sorry I'm having a my is not filtering on my phone so we're going to go next with um how would 7 702 work in stateless when there is no longer a state route I don't see why there's going to be much problem with it and then um how does it compare to EIP 5806 so 5806 was kind of a precursor for some of these ideas with uh making EAS better I generally felt that 5806 for those who don't know is kind of this idea of executing code on behalf of your on behalf of your EA but in like an ephemeral way so the transaction the there might be some code data in it that says you know execute this snippet with my account and this provided some of those functionalities like uh batching but it didn't really provide some of the functionalities that we wanted around uh privilege deescalation or uh gas sponsorship or like speed answering these at this point um can you do recursive delegation you cannot recursive uh delegation basically if you try to delegate to an account that delegates to account uh the EIP specifies that you just immediately stop after the first delegation when resolving