DAPPCON 2024: Demystifying Account Abstraction EIPs - Ivo Georgiev

Transcript

hey everyone I'm Evo georgev from un buyer wallet and I'm going to tell you about demystifying account obstruction eaps erc's RPS you name it as you know it's been a really complicated topic and this talk is kind of weirdly timed in a very good time and bad time at the same time because vitalic is speaking at safe Con on account obstruction um so basically continuing V alic work here um so here is a brief agenda of what we're going to talk about and we are going to start with the big picture and the big picture is going to be like the one scape you're going to see it visualized um then we're going to touch upon ERC 4337 what it is or what it is and what

it is not um then we're going to go into evolution of native account obstruction or enshrining account obstruction into ethereum and the evm ecosystem in general and then we're going to move into intermediary Solutions which were uh which are really popular at the moment um and finally we're going to cover signatures which is just like a huge pain point for DBS um so first of all who Who Am I who are we so I'm the co-founder and CEO of uner wallet and uner wallet is one of the first smart contract Wallets on ethereum entirely uh and it was built in 2019 as part of addex Network and then pivoted into its own thing um spun off

uh and we launched the first one of the first consumer Centric uh account obstruction wallets in 21 and since then we've grown to over 100,000 uh wallets and we also won an account um an ethereum Foundation grant for building email based account recovery through dkm signatures and finally I wrote a very cool ERC for verifying um verifying signatures from Smart contract wallets that aren't deployed yet so counterfactual accounts and you know why is account obstruction valuable most of you probably already know this but I would say that one of the first thing is easier onboarding thanks to being able to pay gas in tokens being able to

prepay for gas and Etc another really cool thing is that we can get rid of your C20 approvals um which is thanks to transaction batching um and also we can recover accounts so you know social recovery onboarding people without a seed phrase uh and letting them recover their account even if they um lose access to it uh and finally Quantum resistance and being able to implement alternative cryptography um and for example implementing pass Keys uh and you can see a demo for almost all of those features in the web version of ire um we haven't implemented like for example pasis yet but we pioner we we rolled out almost all of those features

that are mentioned here uh and another big question is when when account obstruction right and the answer is now so there there is a big misconception in the space about what those eaps and ercs do um because people think that those APS are going to lead to those features being available on Main net but the reality is those features are already available on Main net and most of the eaps and erc's only make those features more accessible easier to build Etc so this is a big like visual overview of the count obstruction landscape and basically things started with um like there's been a million proposals but um

EAP TW uh 2938 was the original native account obstruction and then it evolved into 7560 but that was thanks to year C 4337 um which kind of uh picked things up and became like the ren for account obstruction and a really cool thing about this is that none of those are competing so they're only competing for attention and for memes but almost no almost none of these proposals are competing with each other um so let's start with 4337 and I really assume that most of you are already familiar with it um but there's been a few misconceptions

about it about 4337 to clean up and and uh one of them is that it is a standard it's not really a standard what it does is um it's one of the first account account obstruction proposals that doesn't include any protocol changes so it's really technically kind of a standard for layers a standard for decentralized layers and it implements the feature of being able to broadcast account obstruction transactions and include them uh without actually modifying the ethereum protocol so it's not a change in the ethereum protocol and most importantly it doesn't add any new features um it doesn't enable any new features it just makes building those features easier um it's not native

account obstruction uh that's something that you will hear um many times and it it doesn't it's not enshrined to the protocol which has its own advantages and disadvantages for example the advantages that it's easier to implement and it started a Renaissance in the account account obstruction space but a disadvantage of this is that it comes with additional gas costs so yeah um the benefits it made everyone fall in love with account obstruction again um it was really easy to implement uh in terms of not requiring any protocol level changes uh and the best of all wallets no longer need to develop these proprietary and fragile

reers and unfortunately though it has a few weaknesses like for example uh a high gas overhead the gas overhead of year C 4337 can get up to um 200,000 uh gas or even more and uh it cannot go pretty much any lower than 50,000 gas uh so another disadvantage of 4337 is that it doesn't add any functionality to existing accounts so if you have your your EAS you cannot make use of account obstruction on those EAS and you have to move funds to a different account which has been a huge blocker for adoption in the space and personally I think that this is one of the reason that account

obstruction hasn't seen more adoption because people are just kind of psychologically inclined to stay on their existing accounts rather than move funds to new accounts that they potentially don't even trust because there is a smart contract underneath and another disadvantage of 4337 is that it has a high development overhead compared to S compared to simpler proposals so uh how do we solve this we solve this by enshrining account obstruction as vitalic said and this can come in many forms and over the years there's been literally a million proposals and one of the things that people don't really know account know about account obstruction is that ethereum was actually meant to launch with account obstruction but they

literally run out of time and they were the team was really hard pressed to launch as soon as possible so that's why it get it got left on the sidelines um and yeah we have a screenshot of the original ethereum white paper which literally states that accounts can be contract accounts uh and we have a brief history of all of the proposals so things started in 2016 with uh EAP uh 86 uh and that was basically all about abstracting signature validation and non checks and that was sort of inclined from the perspective of quantum resistance and like alternative signature algorithm but not not only

that um and then after that the focus kind of shifted to being able to pay gas in stable coins or in alternative tokens in general um and then we have we had the first complete proposal in 2020 which was EAP uh 2938 um and then we had this EAP that became so controversial lately which is 3074 and we're going to get to that uh in a minute and then 4337 then there's a bunch of other ones and as I said earlier 7560 which took the learnings from 4337 and proposed enshrining them into the protocol so are any of those live and

almost in all cases the the answer is no but uh some replace the others right so it doesn't make sense for all of them to be live uh but 4337 obviously has been the mo the most successful one and now we come to a very interesting topic from the last couple of weeks and this is uh ERC 3074 and um and ERC 7702 although we're going to get into that uh but the thing is um 3074 has been compared a lot to 4337 in the past like a couple of months ago I've seen tons of these comparisons on Twitter uh and this is um one example there and uh the thing is they do not like they do not solve the

same problem one solves um sending transactions relaying transactions and paying the gas for those transactions and the other solves um converting EAS kind of not not exactly but retrofitting account obstruction on existing EAS um so it kind of started as a very big meme war between those those two ercs or eaps or whatever you call them but both can coexist although later on the 4337 team found that um even though they can coexist it's not really An Elegant integration between them um so yeah herec 3074 was like sideline for like 3 years then core devs uh pretty much kind of randomly decided

to help account obstruction and scheduled schedule the C for inclusion uh and then later on uh the 4337 Community realized there's so many like compatibility issues um and then vitalica came in at the last minute and pretty much saved the day with uh d772 uh which is um sort of a rear Rite of 3074 but in a way that's way more compatible with 4337 and generally more more elegant um and yeah uh EAP 772 is uh EAP 3074 reimagined um it's much more compatible with 4337 as I said uh and uh it doesn't add new OP codes which makes it much

easier to deprecate in the future because argument against 3074 has been that we are enshrining these like kind of ugly hacks and then in the future when we get real native account obstruction we wouldn't be able to get rid of 3074 uh but 7702 solves this uh because it doesn't include any up code changes in the evm it's just an alternative transaction type and a transaction type is really easy to get rid of you just need to get rid of it from the go ethereum implementation or whatever the node is uh and uh basically your you can help transitioning to to full account obstruction to full native account obstruction so um one very significant difference between 30 um

3074 uh and uh 7702 is that in 7702 Contra accounts have contract code during execution and why this is significant because it uh breaks DB compatibility with uh DBS that already discriminate against smart contract wallets so like for example there's been many of those nft mints that check if the CER is a contract and if the caller is a contract they just revert and they don't allow you to me the nft and the logic behind this is kind of stupid they've been thinking on how to get rid of bots and how to disallow Bots from minting their nfts but this breaks the whole account obstruction uh compatibility right so like you cannot

mint it from a safe you cannot mint it from un buyer um but 3074 had potential to solve this uh but with 7702 we wouldn't be able to because the contract still has called the the account still has C during execution but this is actually a really small price to pay because it brings a huge Advantage which is that you can validate signatures through 1271 during execution why is this significant it's significant because like for example I can have my EA and add a pass key to it and without this trade I wouldn't be able to sign messages using the pass key and have those messages validated in the transaction execution um so yeah for everything else uh the trust assumptions

between those two eips remains absolutely the same so you still have to really trust the implementation but that's true for literally any account obstruction wallet and not only account obstruction it's true for any wallet in general right when you put your private key into metamask you're trusting the metamask implementation and the metamask code not to leak your private key so it's pretty much the same with account abstraction when you're putting your funds into an account abstraction wallet you have reasonably verified that the contract that you're putting funds into is secure and finally one of the most interesting aspects of account obstruction and that's signatures um and again there's been a misconception in the past that uh actually this misconception is changing but uh there's

been a misconception that contracts cannot sign messages uh and it's kind of true contracts cannot messages but contracts can can Implement message validation logic which allows the if if it's a contract account um to to define a standard in which uh messages are being validated for example if it's a save uh then the the function would just Define that the message needs to be signed by all of the all of the signers on the save right um so this is an example uh of how uh EAP 1271 Works uh and you define a function called is valid signature and in that function you

will Define your own Logic for what constitutes a valid message for this contract account uh and yeah that's basically how contracts can sort of sign messages they don't sign messages but the signers that own this this account uh sign messages and then the contracts Define how those messages are validated um so there's one big flow with this and it's that you cannot verify signatures from contracts that are not deployed yet uh and why is this a problem it's a problem because we want account obstruction not to make any steps backwards from your ways uh so what we want to do is we don't want the

person to have one additional step to deploy their account uh in the past that was a standard for account obstruction wallets you would sign up and then the wallet would say please pay this gas to deploy your account which is an immediate step backwards from EAS because EAS don't make you do that uh and it's super counter intuitive to ask for someone to pay a fee for something that they don't even know that they're going to use um so yeah a bunch of account obstruction wallets worked like this in the past and then everyone switched to counterfactual deployment which is really cool because counterfactual deployment allows you to delay deployment until your first transaction and hide it hide it from the user completely like for examp example I would create an un buyer account it

won't get deployed on chain so on it scan it would just look like an EA uh but then the moment I do my first transaction uh it would the deployment would get batched together with the transaction itself so the contract would first deploy my account and then it would execute the transaction that I actually want executed so the user doesn't even notice this it's like 40,000 gas overhead uh and on layer tools especially you cannot even know that it's there so we're completely abstracting this step away and safe of course obviously save uh switch to this as well uh but the problem with this is that you cannot verify messages uh if your account is not deployed yet so that creates a whole another drama because I

can go on a DB and the DB could be let's say on optimism and because I've never sent transactions on optimism the DB wouldn't be able to log me in because the D cannot verify my signature um so that's a problem and the way it's solved is through earc uh 6492 which is an ERC that merges all of the different signature types into uh into one single validation contract which is doesn't need to be deployed on chain it gets invoked through it it it co uh offchain and it can verify uh signatures from contracts that are not deployed yet it can verify signatures from contracts that are deployed it can also verify standard easy recover

signatures uh and and this year C extends 1271 it doesn't compete with it uh and also shout out to sequence who also helped with this ERC but yeah it can it that's the main thing that it does it allows verifying any type of signature and um yeah uh we we also built a library that allows you to use the CC really easily so it's like one npm module and we really encourage every DB to switch from e. verify message to this Library because you don't have to care about all of the account obstruction complexities of verifying a message you just have to call one single a synchronous method and you've got all signature cases covered including

EA and yeah um let's go into satellite eips now and um the first thing that I want to mention is modular accounts and there is literally uh the first case of competing QC is here other than uh 3074 um is the case of the modular account erc's which are competing one of them is built by zero def um then we have another really cool ERC which is 5792 which uh allows the DBS to send batch trans transaction batches to the wallet which is really cool because this is the thing that's going to kill erc20 approvals right because uh we don't need to actually qc20 approvals on chain but

we can abstract them away by batching them together with the action and the cool thing about this is that we don't need to make infinite approvals anymore and we can make exact approvals which after the action has been completed the exact approval gets zeroed um so you no longer need to have open approvals and yeah there's a bunch of others which uh I can go into but um what I want to mention is that there's a bunch of VPS now for um alternative cryptographic curves uh which is going to allow us to verify Pass Key is um with significantly less gas so that's cool and I suggest that we move on to questions one question

there uh what is the overhead in terms of gas of uh ERC 7706 uh you mean 7702 uh O2 yeah I know numbers are it's crazy with the vaps and numbers so there's no um it's not defined yet because the standard as far as I know uh is not written to a level which specifies the gas usage of this new transaction type but it's expected to be really low so like for example for 3074 um there was um overhead which is equivalent to delegate call so like a few thousand gas so I'm expecting it to be something like this as well and

another thing word mentioning is that because it's compatible with 4337 uh multiple um like multiple user Ops from different users can be bundled together which can further save gas and can actually make account obstruction cheaper than your ways in other words it's negligible okay thank you very much Eva everyone give a big round of applause for Ev again thank you