EIP-7702: Ephemeral Accounts and the New Security Paradigm for Ethereum Wallets

Transcript

now. >> Yes. Okay, cool. So, yes, uh you you probably know that as Empire wallet for sure, but uh uh I guess this is something that we um should all be aware of and that's why I'm here. Um yes, so the talk is about uh EIP702. Um, a lot of people knows uh this because of like the the story, the drama of an EIP launched in uh less than uh 20 minutes by Vitalik uh with the AA team. Uh but behind it is a lot of I will call it like a superpower for wallets that actually haven't been used yet and the reason is security. Uh so first a bit

about myself. um um uh chief blockchain officer at Kbalos uh protecting 250k users uh with zero loss and uh also involved with the EIL on uh with the foundation building the interoperability layer uh for EVMs. Um so and how I relates to that you got it by the uh by by my background. So been to account abstraction for a long time. Uh adopted very early. Started as a uh strategic researching for by economy back then. Eventually that rolled out into a startup uh uh that was heavily based on account obstruction. Um and

later as I mentioned uh some collaboration with the foundation relates to EIL that is also involved with 437 and 7702. uh about the security aspect of course dealing with wallets users uh is uh uh part of what I'm doing and um and and obviously we will see that how it relates let's do that uh so I do feel the pain I I do know what the issues are and um that's what I want to share today but before that I guess as a start um let's a quick brief about 7702 technically it's about new transa new type of transactions that allows to convert EOAs into smart contract

wallets. Um the problem it it was aiming to solve is the ability uh uh to go to move forward to uh uh account abstraction W based on that like most of the funds are currently located inside EOS inside accounts. So, and 437 actually uh bring the the account of suction to Ethereum uh EVM world, but it was very hard to navigate and that's part of what um messed things up uh before that. So, 7702 7702 allow us to to to shift uh the wallet and not the funds. Um behind the

scene it's actually means to uh the difference between a wallet and a smart contract wallet is two things. Uh mainly uh having a storage uh that's a bit unrelated to to what we discussed today. But the second is having a code hash that is actually a pointer to some code means that uh EOA has no code involved. Smart contract wallet has um actually based on code logic [gasps] and um so we have that but what uh what happens when you have this kind of transaction and the ability to operate really really important efficient uh um uh functionality that relates to uh to

wallets um is that also you get the the downside of it. For example, um since we shift to code, it's actually full delegation. If you if you grant your uh um you delegate to a contract, that means he owns your uh your funds. If it's not not properly not properly handled, then you it puts the user in risk. And um so we move to a um um to a world like that is uh stable to something that is code- based. And in code we have bugs. um it is what it is and in that case you can get like mistakes all but also all kind of frauds and uh and scams start running uh on a

daily basis. The the other thing that is relates to uh 7702 that wasn't available before like for example on 437 is actually the the ability to uh shift to different uh delegators very easily. It's actually a transaction a simple one and on that case you mean user can be some one thing now and the next block will be completely different uh thing as a wallet. So that means it's not just like deploying it at the beginning and you have one version of it. It's actually the vision is that you able to uh uh to put different types of roles or hats as a as a as a wallet and function according to what the the user uh needs

are and that makes it even more complex to uh take over this kind of uh um uh functionality and capabilities. But the outcome is that literally no one knows how to handle it and uh and and uh the the immediate action was to take no actions and not support it. So but hardcoded it's not supported anywhere kind of kind of okay wallet are here but uh and there is uh some uh some progress uh towards 7702 but generally it's not really supported and and wallets u kind of uh take the wool off uh of being a

gatekeeper and decided that they're not going to handle it. There is a one we're going to talk about like the the exception of MetaMask but that's that's the the the outcome and if you have a a hard wallet uh that works with MetaMask you actually have two u uh two layers of blocking uh 7702 because both of them actually not allow it. Um so and there is some reason on what or why they're doing that because it's a lot of responsibility and no one want to be involved with such a thing. Um but there is a question before that we need to ask are they the one to uh to handle this or or be the gatekeeper.

Um couple of fun facts beside MetaMask been uh having their own hardcoded wall 7702 support uh is that someone do use it like very heavily and that those are dexes. Why? because it's a great way to handle funds. uh all the um um temporary accounts created by Dexes uh that user deposit funds or even withdraw funds into uh used before by it's like uh like newly generated and then you deposit funds and if it's not native token you actually need to uh uh they had to deposit uh uh some ETH into it like native token in order to uh to withdraw

the funds from that wallet to other wallets and that's extremely extremely ineffic efficient and very hard to handle because you don't even know how much uh uh gas you need. And on that case, you got yourself into uh uh all kind of dust spreaded all over those temporary wallets. And no one liked to have uh a fund spreaded with no use. So Dexes are using that. But again, what they did is to have their own version of 7702 delegator and to uh to use it internally. Um so again it's not I won't consider that as a as an adoption uh but it does prove the um uh the ability to use it properly and to

get a lot from 7702. Okay. So now uh once we we we uh we nailed that I want to move to like the next step of a discussion about what is missing. I'm not sure about discussion but to at least list what's uh what can be very handy in order to solve it and you probably won't see answers over here because this is still an open uh um uh question. Uh and the challenge that it can be reflected to any other security that involved with the smart contract wallet. um uh but at least we can see like take examples from other places and

see what can be done in order to solve it. So as I mentioned g the the gatekeeper role is something that um like uh actively taken by uh the wallet decided to um they are going to handle it and not let anyone else uh uh or at least block it on their layer. And that means like anyone else uh cannot be involved with that. Um and that's a good question because like for for example we uh at Kellos do that such of gatekeeping way better and and more efficient. So in that case uh it's maybe best for wallets to not be involved in anything and just to have the user the ability to pick who

he who he wants to uh to protect his uh transaction, his funds and his functionality that relates to his wallet. Um but still now that's the situation. In order to hack it, it's it's a hack. But if you want to get your wallet as a smart contract wallet, you actually need to take your um your uh uh private key and like script the the transaction in order to make this uh um this account as a smart contract wallet. But it's involved with many issues. It's it's involved with exposing your uh your uh private key and so on. not recommended for sure. Um so right now we are blocked and uh hope for the best uh that the next will will change that. So

again the gatekeeper role is one thing. Uh but let's see what else can be done. So first communication assume that we want to have not just a single contract. We want to have multiple sometimes having different types of roles dealing with different challenges and so on. on that case we won't have uh uh we want to switch from one delegator to another someone need to have this list or someone need to have the ability to decide what on that list so first communication is part of it now it's actually handled by each wallet or not at all as I mentioned it's hardcoded so uh that's the best they can do right now but obviously there are better solution for that uh I guess the best one is onchain uh storage for this in the way

that um it's blocked on the transaction uh stage anything that is not whited whitelisted or not um allowed to be delegated to uh it's by the way it's way better than have that on the the extension uh code um of any wallet that is blocking it right now. So that communications is once because we want to have that list and we want to have it also dynamic. It's going to grow or shrink. Uh but uh um so so it must be something that a bit better than just like hardcoded into um JavaScript extension.

The ownership of that white list that's also something that need to be handled properly. So if we have multiple wallets and each one of them has its own uh list that's going to be an issue. Um, and assuming that some wallets actually dominate the market, that makes that gives them a lot of power that as a users we probably don't want to have. Um, so taking this list out and have the ability to create some kind of a committee for example as I mentioned uh will probably do uh a lot of good to uh uh to the users and the adoption of 7702.

But it can be handled like in way many other different uh ways. Um but for me as long as it's like not separate separately uh managed by each uh wallet uh that's probably will be uh uh way better solution. What else? Um and yes, so we discussed um that we need to validate some some contract and that's like an issue with anything any smart contract uh not necessary wallets that to be defined as safe or not. Right now it's uh one big of a challenge that uh there's a lot of um there's a full industry trying to uh uh get that in place. Still not there.

So in that case again um to create some kind of a way that people can submit their delegators and they can be validated need to get into a uh uh higher level of confidence uh in a way in what we can allow as a delegator. So probably need a definition of what's uh allowed and how to make it happen. uh it can be like as an interface or some kind of a guidelines that help um who building delegators to put that to put them in place and we don't have anything related to that. Um not even something that will say okay let's make it like a flat contract make a specific calls or

some kind of uh functions that should be supported. It's uh it's basically nothing. I think that's um obviously the next step uh moving forward the 7702 and without it we're not going to have the real experience of multiple delegators dealing with different challenges um and let the user switch from one wallet position to another. Um okay. Um so that's kind of like uh just a bit of what can be done. Um the industry still not there or not going there. Um but uh future says that since we're going to get uh um soon I hope u

account abstraction integrated into the into the call protocol with 7701 um that will definitely makes uh um uh things way brighter and put us in a position that uh that we uh users and actually the industry will um move towards 7702 and accelerate this process. Um the majority of it is still uh a bit behind but we're going to see that in the next couple of months um um once the once that will be involved and I guess uh that's it question

>> but uh be easy with me. Okay. So, um first of all uh a correction. Um buyer also implement 772. So, thank you for mentioning in the beginning. Also, I think you meant centralized exchange deposit addresses. Um and the question is um so 7702 uh makes a lot of sense from the wallet perspective because the wallet provides some functionality for the user and the wallet knows what the exact interface of the delegator is. If the wallet were to support a white list, a full white list of delegators, then it doesn't make so much sense because the wallet has to implement for each of these delegators a custom interface for batching. A c partially custom for gas obstruction, not so much because of

4337. Uh but for a wallet from a wallet perspective, it makes a lot of sense to have your own delegator. Meanwhile, from the DAB perspective, 7712 doesn't make so much sense because even though it simplifies some things, uh the DAB can implement a lot of those things really on a DAP level like uh for years the industry has been using multico and has been inheriting from multico. So if you want to do uh batching on a dub contract, you can do that more easily unless it's some composibility use case. So 7702 is like this is pretty much a universal consensus that it's kind of a way for uh the protocol of communication is between the wallet and the delegator. Uh and the white list really makes sense for

hardware wallets because hardware wallets are kind of just like pass through of course except clear signing which is another topic but they're just kind of passed through. So yeah, for hardware wallets a white list makes sense, but for extensions I think each of them make it makes sense to have its own delegator and understand the protocol of speaking to that delegator. >> Yeah. So uh just a bit of a context um we are both biased. So I'm I'm coming from the like uh security extension uh perspective and uh Evo is from the wallet perspective. So definitely uh uh we we share some different perspective.

Um but also we work together on like the EIL project and uh supporting uh and also on 7702. So uh Evo definitely know what he talk about. Um but yes I understand why wallets want to have such kind of a uh position of like okay we know how to handle it. It's better for us to support it properly. Um but again like uh we list a couple of uh elements that can be relevant. One of them is a standardization of the of delegators and on that case it's going to solve what you mentioned as like we need to support different functions different functionality and so on. So you need to have the full pack and on that case it

will make it it will make it much easier to uh uh to handle for wallets and for users also. >> Actually uh I might I might argue that if there is such an effort to standardize everything then there is no point of multiple delegators to begin with because the EF can just make a delegator that everyone can work with. Like one example of this is if we had a standardized interface for botching, we already have a standardized interface for gas abstraction which is 4337. So in this case like everyone can use the same delegator. Um but yeah and the other thing is if a wallet extension is built to work with its own delegator then there's no there's no security problem to begin with. Uh but I do agree with you that the security problem still

exists for hardware wallets because they still need some authority to tell them look those are the this is the white list. Uh yeah I I uh about standard standardization I mean by that like there's some kind of a sense of standardization to start the process not necessarily full and I and I mean by an interface and not necessarily the the functionality behind it and the context of uh of having like multiple uh delegators is is to have the ability to uh to use different validators for different reasons. So you have a specific functionality. It's not a full wallet. It's just like a specific functionality and you shift between delegators according to what you to what you want to do now um like uh for the

close future and so on and on that case it's like it does make sense to have multiple >> yeah was a good example >> exactly it's a good example but yeah it's it's a long discussion uh so yes anyone else you want to ask something >> no you don't want to ask something Okay. So, thank you. >> Thanks.