Ivo Georgiev - Demystifying account abstraction EIPs

Transcript

so uh good morning I'm Evo uh and I'm the CEO and co-founder of uner wallet and I'm going to help you demystify all the account obstruction ercs eips rips we're not going to go ahead and uh dive into what any of those letters mean uh but uh all that's all that matters is that those are proposals to improve ethereum and evm ecosystems and there is millions of them uh regarding account obstruction uh and uh a quick agenda of what we're going to go through first of all uh the big picture stuff so what are all the account obstruction Improvement proposals uh then we're going to go into

the biggest one earc 4337 biggest one when I say biggest one I mean biggest one in terms of Mind share and in terms of how it captured how it captured our community and how it reignited the vision of account obstruction uh we're going to go into what it is not uh and then we are going to do a deep dive into native account obstruction what's the state what we how are we doing in terms of native account obstruction in the evm ecosystem and on ethereum and then finally we're going to cover smart contract signatures uh and a few other eips that more or less help the account obstruction ecosystem but are not directly related to account obstruction

so who are we uh when I say we this present presentation is brought to you by am buyer in general it has been a team effort uh I already presented myself but um what are M credentials well um I'm buyer spun off of addex and addex was one of the first projects on ethereum to ever deploy a smart contract wallet uh back in 2019 and back then the only other smart contract wallets were uh parity and agnosis safe which later uh turned into safe obviously extremely successful um we also rolled out one of the first consumer Centric account obstruction wallets at the end of 2021 uh the UN buyer wallet and uh it's currently a web wallet but we're working

on an extension uh we won a grant from the ethereum foundation for building account recovery through uh email uh so like being able to log into your ethereum wallet with an email and a password but while keeping a fully self custodial nature of the wallet uh and finally um we created ERC uh 6492 which I'm going to go into later so why is account obstruction valuable I guess most of you already know this but um let's have a quick summary of everything so you can get onboarded much easily because you can eliminate the seat phrase and another big point of onboarding is paying gas with non-natives and paying gas with tokens

because we usually we think of this as a feature but it's not so much as a feature as it is an an ability to onboard users because one of the main points of friction for new users is having to get e or whatever the native currency of the rup is so this friction of having to get e uh makes people sign on to centralized exchanges and we don't want that because people end up sticking to centralized exchanges we also don't want it because it really doxes your wallet so for example if I make a new wallet and I need ease for gas I'm going to ask one of my friends to send me some eat for gas and then I'm kind of doxed because I'm creating this relation between the two world so that's not ideal uh of course we have account recovery like what Argent did with

social recovery um and a bunch of other account recovery mechanisms as I mentioned earlier the one we won a grant for uh the one with uh email uh and of course you have alternative signature algorithms which is also hugely valuable um because you can validate pass keys from iOS devices uh you can validate um web authentication from web browsers uh you can use secure enclaves that are already on the devices that we have so like why reinvent the wheel why use um different signature algorithms when we already have secure enclaves on our devices um and we've buil sort of a demo for all of those and of course we have to ask ourselves when is account

obstruction coming we all know that uh that's a painful issue and we already know that there's a lot of Wallets on Main net already that Implement a ton of account obstruction features Argent was one of the first ones but in 2018 they launched and they launched on ethereum so even back then we had account obstruction uh but the the purpose of all those eips erc's and Etc is to make account obstruction more accessible uh and to allow it to get adopted quicker uh and basically to give developers better tools to to build it faster and to make it uh to basically make it usable uh and this is a huge bubble of the entire account obr rtion space and

we have EAP um 2938 uh which was the one of the original account obstruction proposals back in 2020 it wasn't the first one but it then evolved into this rip which takes the best from IRC 4337 and makes it native uh which is amazing we're going to talk about it later but there are two key two um key takeaways from this slide so one of the one of the key takeaways is that none of those are competing and that's really important because a lot of times when we think account we think about account obstruction we think about this earc versus that ERC but in reality that's just not true you have all of those erc's which are mostly complementary to

each other almost none of them are competing uh and uh sort of they all have the same goal but they all tackle the problems for tackle the tackle different problems or the same problem from a different direction in such a way that they can work together and yeah none of those are um are conflicting and uh the other takeaway is that we need many aspects of account obstruction to work to make it to make it work basically and uh the other key takeaway here is that we have a key intersection uh between a few VIPs where we need to be so like for example uh in order to to have account obstruction right now in a pretty reasonable way and to make it

developer friendly we need ERC 4337 but then uh to make it truly native and to make it cheap in terms of gas we need RP uh 7 75 60 and then in order to get signatures to work we need the ercs on the bottom so we need everything together in order to get account obstruction going so yeah none of those are competing they are competing however for attention and for memes as you might know from Twitter so uh a quick recap of 4337 uh and and the revolution of 4337 really in its Essence is the fact that it doesn't require any consensus level changes and this is something that the ethereum community kind of realized that

you if you want to make account obstruction work you need to make it as least disruptive as possible because previous ercs arguably failed because they required way too much changes and on a main net that's already live and it already has a t tons of DBS deployed and every Small Change in the evm can bring security is issues that's kind of an issue so you cannot simply change the evm uh you need to you need to avoid this as much as possible and ERC 4337 is the first account obstruction RC um to be entirely on the application Level so another question that people um that people kind of get and that people sort of don't understand is is it a standard and the answer is really

complicated you can think of it as a standard for relays because as I said we had account obstruction before it and account obstruction was largely built on these proprietary layers uh that you send u a transaction like object which is also signed using some signature algorithm to that relayer and this relayer used the new way under the hood to make the transaction confirmed on Main net and the way that ERC 4337 changes that is it allows anyone to be this relayer in the form of a bundler and it standardizes the communication between the wallet and the entity that relaying this transaction to the to the actual blockchain so that's what it does it allows a network of bndw and as a

result a public mol and as a result account obstruction kind of gets the same benefits as uh Native EA transactions so uh what is what earc 4337 is not uh it's not a change in the ethereum protocol uh it does nothing to change the actual ethereum protocol uh it does doesn't add new features or functionality to Smart accounts even though uh a lot of the marketing material for 4337 was related uh to those features that it's going to bring to main net it doesn't actually bring those features to main net it just lets developers uh build them easier uh build them better and that's really valuable

in itself it's amazingly valuable but it doesn't add features right um so it's not native AA we covered that and it doesn't actually do anything to standardize accounts this is an interesting point that but a lot of people have been understanding wrong um it doesn't standardize accounts in any way uh it just lets bundlers and wallets talk to each other so that's an interesting point because accounts can still have different interfaces between different implementations like for example safe can have one interface and non buyer can have a totally different interface um and then finally there is nothing cross chain or intents related to your C4 337 and I'm only mentioning this it might sound weird because I'm only mentioning it because I've heard

some people make this uh like be confused by that point and think that EC 4337 is somehow related to intents it does help account obstruction happen so it does help intents happen because account obstruction is kind of an important step to intent uh but it doesn't it's not related to intents directly so what are the benefits so the the the biggest benefit although that's a double edge sword is that it inspired developers to fall in love with account obstruction again when I say a double- EDG sword um I tweeted about this recently uh it's about the fact that many people were hyped from your C 4337 and then when adoption didn't happen super quickly as everyone expects in

crypto uh people sort of became disillusioned with account obstruction and thought that something must be wrong with it which isn't the case Obviously good good things take time uh but this hype this hype train that it created sort of backfired a bit but in general it's really good because every everyone now is thinking about account obstruction and like a couple of years ago DBS never thought that account that users can be contract and now DBS know very well that users can be contracts so they build with that in mind uh as I said there's no consensus level changes with which helps a lot for everything to get done to get implemented uh and the biggest point that ERC 4337 helped with is that wallets do not need to spend

time to develop these proprietary and fragile reers which took a lot of effort to happen basically and obviously we have a lot of improvements in terms of censorship resistance which is what we want uh and uh it standardized smart account user operations which is as I said the the structure of data which is similar to EA transaction and uh finally we have pay masters which is really a huge part of the standard which is uh a lot of people think that pay masters are for sponsoring gas they're not necessarily for sponsoring as in someone else pays pays for your gas there are for um for allowing gas payments to happen in many different ways it could be sponsored by

someone it could be sponsored by the DB it could even be sponsored by the network in a rup uh or it could just be paid by the user uh but paid in near C20 token or paid even with an nft let's say or paid with a with a deposit that you made earlier on so yeah when when people talk about sponsoring they don't mean that someone else is paying it uh they mean that that the pay Master gives the is and then the user gives some other form of value to the pay Master uh it could be just the network effect from using the DAP and so uh let's switch the topics a bit and go to Native account obstruction um and there was already a talk uh by Argent about why native account

obstruction is important and we totally support this but uh it's going to take a while for it to happen on ethereum but something interesting that you may may have known or may have not known is that ethereum was actually meant to launch with Native account obstruction who here knew that anyone okay so ethereum was meant to launch with account abstraction uh but uh due to time constraints they didn't ship it and there's actually an a piece of text from the original white paper here saying that there's two different account types one of them is a Neway and the other one is a contract out of context it's a bit um tough to understand this but basically ethereum also meant to have contract accounts be

able to initiate transactions themselves this is the actual account obstruction feature that never happened for contracts to be able to initiate transactions so what's the brief history so after ethereum sort of um had was when this was in this rush and didn't ship this feature vitalic immediately started drafting a few uh a few eips on account obstruction the first one was 86 and that one didn't happen so it was kind of Rewritten to 208 uh and back then the point was to abstract the signature and non checks so this would allow for contracts to initiate transactions but it isn't quite the same as the uh Native account obstruction near SE that we have now uh and then

vital a really good blog post on the challenges uh behind native account obstruction and generally a lot of this was related to the current challenge that TC 4337 has which is how to make sure the transactions cannot be arbitrarily invalidated right because like for example imagine that there is a thousand uh smart contract transactions in the M Pool uh but unlike EA transactions their validity doesn't only depend on the signatures it could depend on some contract logic right so like changing one storage slot in one contract can invalidate all of those thousand transactions like in a in a Flash in a second so the problem with this is that the network becomes really um like um really exposed to spam issues uh and it's possible to just like spam

millions and millions of transactions which would be considered valid in the M Pool uh but like in a in in a Flash they could be invalidated uh without any way to predict this so IRC 4337 solves this by introducing some storage constraints uh and all of the account obstruction uh EIP zcs have some sort of mechanism for this and then um then in 2020 there was a more mature account obstruction proposal but didn't happen due to requiring a lot of consensus changes and having a lot of security edge cases that we couldn't possibly address on Main net uh and then we had um EAP 3074 which is really interesting and uh Erp um EAC EIP sorry uh 503 which is uh which is

complimentary to this and those two are fully um are totally different from the previous ones because they do not introduce account obstruction they introduce an ability to convert EAS to contracts which is extremely helpful for account abstraction but it isn't account abstraction right so it doesn't allow us it doesn't allow contracts to initiate transactions um but it does allow existing Wallets on the main net existing EAS to convert to account obstruction which is really cool and it would be amazing for adoption and those VIPs kind of died for a second but uh they got revived recently and they got revived in a way that's really funny by having this meme war against 4337 which isn't even uh technically accurate right

because they're not competing standards uh but the fact that uh it got memed a lot uh means that those that this got revived and then finally RP 7560 which is absolutely amazing in my personal opinion because it combines all the learnings from everything that happened before uh including a lot of valuable learnings and a lot of valuable development from 4337 but makes it native uh makes it enshrined into the protocol and why is this important it's important because it gives us um it gives us the best of all worlds and uh it gives us cheap gas for account obstruction uh for account obstruction transactions because at the moment for

4337 we have an overhead of like 60,000 gas which we cannot get rid of it's absolutely impossible and like for Native like just for sending e for Native transactions this would make it four times more expensive and this RP solves this so I meant to write something about vitalic on the bottom but I forgot what it is and I guess it got stuck in a draft so anyway uh so are any of those live absolutely not none of them um but uh we're working on it and uh the last one has a really big chance of becoming live very soon in uh in a ow up I'm not really sure which one but uh it's definitely going to happen and there's already an implementation in go ethereum which is

the furthest any of those eips has ever made it and a really important Point here that I already mentioned those two can absolutely coexist one of them is meant as I said for converting QA to Smart account and the other one is meant for relaying transactions absolutely no competition but there is a competition for attention right and finally one of the biggest topics is signatures so basically a lot of people think contracts cannot sign messages and that's technically accurate um however contracts can Implement logic that states which signature is is correct so how this looks uh imagine that your wallet is a contract which is

obviously the case with account obstruction uh and um for this smart for this smart account a valid signature would be the signature uh the the elliptic curve signature for which there is an autorized signer with with this contract so the contract would keep a mapping of the valid keys and then if if you have signed with a key which is considered valid by the contract then it's considered a valid signature for this contract and by extension for this uh account so yeah this is how this looks in practice and uh basically this is erc1 1271 uh the standard signature validation method for contracts this is

how the interface looks like you can see it's almost the same as my example I've actually flipped signature and hash but that doesn't matter here um and another peculiarity of this standard is that it doesn't return a Boolean but it returns a magic value and the reason for this is that if you're uh if you're validating a signature and it accidentally goes into a fallback function that for some reason it happens to return true or one uh then the signature would get accidentally validated and that's why you don't want this you want to return a magic value uh which there is a very low chance of a contract just returning run rly is this a solution for contract signatures unfortunately it turns out it's not after many years it's still not adopted and it's great actually the adoption

issue has been an issue of uh like mostly convincing DBS um but there is one big flow with it and the flow is that um you cannot validate signatures for contracts which are not deployed yet and that's a great technique that many account obstruction wallets did they don't deploy your account your account contract until you've done your first transaction which is hugely valuable because it eliminates One Step from the process and it eliminates one uh like one fee payment and how is this solved uh with ERC 6492 uh Universal signature verification so this is ANC that extends 1271 it doesn't compete with it it completely

extends it and it allows for very easy verification of any type of signature including traditional EA signature but also to verify a signature for a contract that isn't deployed yet uh and that works basically in a kind of in a magic way um through um through an eth Co which does which deploys a contract but it doesn't really deploy it because it's offchain uh it's a bit crazy that how it works if you want to learn more about it just uh read the ERC it's really cool and a lot of erc's have been replicating this magic deploy lless method of calling contracts and yeah this earc can verify any signature and it can also verify signatures for contracts that are not deployed yet therefore solving a big ux

uh battle between counterfactual deployment and being able to verify signatures so a quick um a quick rundown of the satellite ercs and when I say satellite I mean things that are not strictly account obstruction but help account obstruction a lot and uh the first one is modular modular accounts uh there's been two years SE uh some of them are supported by safe and zero Dev uh and I think those are the first case of competing qc's that I have on my presentation uh and then you have the wallet function call uh and this is really cool because it it enables daps to tell wallets uh to to make you sign multiple actions at the same time which is great for eliminating erc20 approvals

we all know how bad approvals are uh and this ERC enables the ability to do exact approvals every time without having to do an actual additional signature and exact approvals are amazing because they cancel out automatically after you do the the operation so like imagine you do a swap you do a swap for 100 usdt and then the approval is only for 100 USD and it doesn't require an extra signature so you don't really notice it uh and there's no open approvals left to the DBS so there is no like security risks in this it eliminates a huge amount of uh security issues as you all know and then we have uh precompile for uh the nist curve uh which is a cryptographic curve that you have on iPhones you have on multiple devices uh

and you have Diamond contracts which allow building different sort of upgradeable and flexible account and finally we have one thing which I think the number is not correct um but it's something that the wallet connect team is also working on which is a user operation Bund which standardizes the way or more like it allows for a way uh for a Dap to build a user operation in a way that's compatible with the particular account because I said different accounts have different interfaces uh how this might look one one account may have an execute function and the other account may have an execute full function which takes different arguments so this user operation uh Builder uh EAP allows this uh to be uh allows ad D to know which standard or which interface the um the

wallet uses so yeah that's pretty much everything um it has been a lot of stuff so I hope we have time for questions evil thank you very much for search a reach and interesting in presentation unfortunately due to time we are not going to open for questions right now but uh Evo is pleased to help you and to attend you outside in the CER or even you can reach him out through Linkedin yeah and on X and warcast I'm sorry for that but we are late on time so thank you very much thank you