Account Abstraction Panel With Yoav Weiss and Kristof Gazso I Pragma London 2024

[Music] welcome back everybody hope you enjoyed uh your lunch we are ready to resume the rest of the afternoon with the remainder of our talks interviews and panels so let's get right into it the next thing we have is our second and final panel of the day we're going to be talking about the state of account abstraction you may all have heard about the word account abstraction by now or AA or the the EIP 4337 there's a lot of things that have gone into the the full amalgamation of where things are at now and uh where things are going and uh we're going to be doing a discussion around the state of account abstraction what's upcoming how it's been so far and uh to have this conversation I want to bring on our two amazing panelists yoav and and Kristoff on stage uh these two are the authors of the EIP 4337 one of the two authors of the the uh the proposal and we'll be discussing the future and reflecting on the past for recan abstraction so please welcome them on [Applause] stage you have Kristoff uh welcome we're uh we're going to touch on a handful of things on how things got started and of course uh where things are headed but um one interesting and uh and awesome thing here is that um it's just been just about a year exactly since we've had 4337 go live um with the Nuance in there and how we Define it uh so the question I have for you is um can we talk about how um this has been so far and just kind of what the state of kind abstraction is yeah yeah so um so I think it's a it's going well looking by looking at on chain stats and and number of projects so I'm seeing a lot of great uh think a lot of great projects being built lot of sdks new wallets many projects make things that wouldn't be possible otherwise like using uh using the phone secure Enclave which in order to sign transaction which has been a long time dream of mine to uh to see that happening and uh looking at uh just the onchain stats I think there's last time I checked more than 3 million accounts deployed and 13 million yeah thanks and and 13 million user Ops so yeah I would say it's a gain traction and it's h but we're only just getting started we haven't even launched the public M Pool which is uh probably going to happen very soon so um there there's a lot going on that sounds like a pretty good year yeah just to add to that um you have you mentioned 3 million accounts 30 million user operations also it's interesting almost $2 million of gas has been subsidized by uh these things called pay masters which allow you to U delegate gas fee payments to third parties right so we've seen a lot of people um looking to sponsor away and Abstract with the gas fees for end users to make it easy for them to on board to their applications right we've actually seen I think quite limited use of one of the one of the early Promises of um smallart accounts of account abstraction which is erc20 gas fee payments right that's actually something that really surprised me um over this past year um and I feel like it might become even less relevant moving on in the future given how low gas fees people are expecting especially on rollups nice um well that mean that's just the the last year of of growth but uh maybe it it'll be helpful for us to understand how did this actually came to be what motivated you to create this CIP and uh what was kind of the early sort of frustration points and compared to the other Alternatives alternative at that point like why was there this inherent motivation to create a new or better standard or improve on what was out there mhm so uh first uh one important point is that's an ERC rather than an EAP and it's important because because it's important because that's that's what made it unique and allowed us to start H moving forward so account obstruction has been has been a long time plan for ethereum vitalic actually wrote the first post about it h in a in a 2015 before ethereum launched and since then the many eaps were written trying to solve account obstruction now uh it's it turns out that it turns out to be a difficult problem and it's really hard to agree on a protocol change for something this complicated and be opinionate about it before knowing what actually works so what we decided to do is a 437 is to uh is to try to create it as an ELC and Implement a smart contract instead of like a single Singleton smart contract called entry point instead of doing a like instead of doing a protocol change Implement a protocol into a contract which is H slightly less efficient but it allows you to start experimenting without waiting for a consensus change so that's what led to this ELC and now it allows us to see what actually works before deciding to enshrine it yeah I guess expanding a bit on that zooming in um at least from what I recall the way um this ELC specifically started is there was you know a very small telegram chat with some people from from the EF uh me and a couple other people and you know we had some hackmd document that we were looking at how this could potentially look and then it was just a very quick iteration and all back and forth um between you know coming up with a spec adding some restrictions to to the validation and you know making sure there's no deil attacks and then implementing it in a prototype bundler and then going back and forth over and over again being able to iter it very fast so this is not as possible with a consensus change right with a hard Fork real EIP because there you have to get things right in the first go and so we've seen that you know there's been a couple entry point upgrades since this ELC has um come up as an idea and you know this is not really possible with hot Forks right so I think that's a big reason we've seen the growth that we uh that we've seen so far um so maybe I'll just going to jump directly to you Kristoff what what is the current definition of account abstraction and effectively what does it let you do um and uh let's kind of do that by by example Yes actually there's a lot of um confusion and rightfully so between some related terms like account abstraction smart accounts um so account abstraction the way I like to explain it is that in in the ethereum protocol there's currently two types of accounts there are these so-called EA accounts externally owned accounts which are the typical things you usually interact with when you use things like metamask right these are accounts that are controlled by a single private key um that you store offchain right and so um you typically interact on chain with these you know defy apps whatever apps you use which are smart contracts and now the idea of account abstraction is like hey actually if you look at these EA accounts how they work is extremely hardcoded there's a lot of um hardcoded definitions about in which they were designed at the Gen of ethereum some examples on like the fact that um you have to pay all the gas fees in this currency you know ether right and you get refunded any unused gas um back to you at the end of the transaction right and you cannot pay with any other tokens you have to use one specific signature scheme you cannot use things like pass keys or face ID or you know Quantum resistance signature schemes natively with these types of accounts and so the idea is that okay what if we actually relaxed these assumptions that the ethereum protocol hardcoded into how accounts work at the start so with smart contract WS with account abstraction um the idea is to make it so that these accounts are a lot more flexible you're able to Define exactly how your accounts work with custom evm bite code and that actually allows for a wide range of possibilities you basically have you know Che and code uh Che and complete access to whatever you want to do with your accounts you can do things like gas sponsorships like um um eos2 token payments you know use any syger scheme you want add modules you you know really the possibilities are Limitless and um yeah smart accounts are just the actual term people like to use for what if our accounts are you know onchain smart contracts account abstraction is thatal in protocol change that makes them first class citizens in ethereum anything want to add or that was a pretty good description yeah I think it was um kind of do a followup to you Kristoff U so you decided to also create a company around this and um the thing I'm kind of curious about is uh what's that Journey been like and and more specifically um were there any points in uh in actually implementing the standard then you realize oh I could have done this better or realized that there were some Kinks that could uh were just not obvious at that point uh of of kind of writing the spec but only kind of came in when you were implementing it what was that transition of the research going into actually implementation part of the reason um you originally I was very involved in the research uh and prototyping side of this ERC but I realized that you know my my uh my abilities do not really compare to all the people from the EF there so I saw um the most leverage I could have to actually making smart accounts a reality making smart accounts a default for ethereum users was building out the necessary tooling infrastructure products that make it very easy for Developers to get started with smart accounts right it's all it's all great having a standard out there but if you don't have the tooling the INF necessary for people to build on it it doesn't really account too M uh too much and Journey's been very interesting um definitely the problems are a lot different than when you're doing research you know most of your time ends up being spent talking to people uh whether it's you know sales hiring whether it's talking to users to develop better products improve your infrastructure um talking to developers what they like when it comes to sdks tooling what's missing in the space yeah I would say um the cool thing about this ERC and the reason you know I didn't have too many surprises when it comes to actually implementing it on the product side is that it tries to be quite minimal right it just tries to Define how validation Works how you're able to call Smart accounts to make sure they end up paying the validators for transaction fees and everything else it leades up to the rest of the community right so things like um modulus smart accounts uh things like you know security of smart accounts that ends up being defined by these different erc's that being worked on by different teams got it um we've talked about so you kind of talked about pay masters and um and how they kind of let somebody else effectively sponsor a transaction so you don't have to pay the gas as a user um is it part of the the spec here that it has to be about ethereum or is that the payment currency must be e it's itself or can we actually pick any any token here and um just kind of make that work how much of that is opinionated by the spec the spec is not opinionate about it at all and in general the spec the spec try to be H to be UN opinionate about anything that doesn't involve protecting the protocol itself against denal of service so it's not opinion about validation about the methods of validation only about how it's called so when it comes to gas sponsorship like a pay masters the pay Master is just a contract that U it's just a contract that gets called if you specify a contract for your transaction for your res operation then it's being called and if it agrees to pay then it pays now it can do whatever it likes during the during this uh this event so for example it could pre-charge you with a with usdc which uh some pay masters do so in that case in that case from the user perspective the Gas payment is done by usdc or whatever ELC 20 token and the pay master pay pays e so transactions must still be paid by E because that's how ethereum works but it's h but it becomes transparent to the user you can have any logic whether it's charging by tokens charging by Fiat like you know maybe you pay you buy some gas credit with a credit card or whatever that's a pretty good description honestly um the way I like to describe pay masters to try and make it very simple is imagine a contract right just a simple contract that is ask hey do you want to pay for this transaction and it's literally its only responsibility is to look at that transaction look at all the data that's in it and say yes or no right so it's as as y have said it's supposed to be extremely minimal when it comes to the spec but that means it's allowed to do a lot of very interesting logic um so again things like uh sponsoring from say offchain credit card sponsoring using EOS 20 um tokens uh you could do you know again it can be completely custom right flip heads or tails and if it's heads then you know you sponsor the use operational um so so it's really really flexible nice I want to do a one other kind of effectively FAQ here um how much of what we want to leverage with the account abstraction here is specifically tied to having a smart wallet versus just an EA um like is it effectively forcing everybody to have a smart wallet does it mean like you can't get half the things you want or like we we want this to be the new default what's kind of the stance that uh we get to take as uh as considering kind of best practice so I don't think we I don't think we're forcing anyone to use anything so uh if you want to use an EA use an EA but uh it's um but I think that as time goes we'll see less and less users choosing that because an eway I mean so it's an I mean you asked how much of it is about smart accounts I would say 100% because it's uh I mean moving a smart account just enables you to do a so many things that an EA doesn't an EA is extremely opinionated it's it has exactly one type of authentication using an ecdsa key you cannot have multisig you cannot have you cannot have other signature types and it has no authoriz no separation between authorization and authentication which any other security system has we actually the authorization is a fixed so that if you have the key you have you control everything and if you don't have the key you have nothing you can't do anything and it's opinionate about how the call is executed you cannot do batching you only have like a one transaction one call and as Kristoff said it's also there's a gas sponsorship is not possible so you have to be you Lo all yeah like I mean the account has to pay the gas itself in E so it's extremely opinionated about everything which means that it actually fits a very narrow a very narrow subset of the users and I think that in order to fit a wider uh like a wider audience we need to make it abstract we need to let different people have different methods so over time I would expect that uh this will become the norm interestingly while it is true that account abstraction is specifically for smart accounts right now there are potential ways of making it easier for EAS to start getting the benefits of smart accounts or starting to convert to Smart accounts right so there's ideas about how we could try and migrate uh make it possible to migrate your existing EO account to be a smart account on chain right so imagine a a special transaction type or a special op code that can convert your existing metamask account into a custom Smart account that has any authentication any logic that you wish without having to migrate your existing assets or even you know having to migrate which is not possible your soulbound um tokens soulbound nfts so there are examples like this which can make that transition easier so regarding a transition that's something I mean I I have to comment on that uh while it's a it's a highly requested feature and we should support it we should have a migration path I think it is also often it is overlooked there's there are risks that cannot be mitigated so I think this should not not be the default path it actually this this feature is geared towards a it's a it focuses on existing users that already have an eoa with many assets and need to convert but the next billion users shouldn't start from in way they can start from a smart account from day one and not have to convert and the reason why this solution would be superior is thatth if you converting from an EA it means that the ecdsa key for that EA remains valid in some places for example on other chains so you claim your account on one chain and you migrate it but then on another chain someone is on another chain if you if someone steals the key they have access to it and if you burn the key then you cannot claim this account elsewhere so it means that you still have to protect an ecdsa key which is kind of the whole point was not to have to do it and even on the same chain for example if you you have contracts that use EC recover to check the key like with a you know like permit so if someone steals your private key after you migrated to a Smart account and you no longer use this private key someone can still sign permits in order to drain to drain your account so I think migration is an important use case but it should never be the default for new accounts just so we don't agree on everything in this panel uh make a bit more interesting I agree that you know this is not a solved problem migrations uh but I actually I would kind of contest the logic that okay the vast majority of users currently are using um eoas but obviously the next billion are not going to be using EAS they're going be using smart accounts I feel like there's quite a bit of network effects when it comes to what accounts uh new people coming in are going to be using right if if most developer tooling is still for Eos if most existing wallets are still for EAS you know the the the marginal next user is likely going to be using that even if um technically smart accounts also Parry up so I am definitely still very curious very interested very uh motivated to try and find paths to migrate existing users as well I mean it does come down to effectively what the defaults are for the things that are actually driving a lot of the the user adoption and um you kind of get to think about what is it that we want to effectively offer as as a good experience um it's been a year we've T talked about what 3 million accounts so far um millions of dollars in in gas subsidies or sponsorships and um the the standard is not super opinionated so does that mean we've kind of solved the count abstraction it it's done let's just kind of wait for it to just get bigger like is that is that it like what's actually next can we still improve things if so what's actually in the works and uh and I guess I'm curious about like what is the actual future look like of making a account obstruction even better no so I wouldn't say that we solve the account obstruction we're actually just getting started um so 437 focuses on validation because this is the minimum viable protocol to have a the to have account obstruction with decentralization not sacrifice things like sensorship resistance and then the protocol deliberately didn't try to Define other things so as Kristoff said earlier uh we are Miss missing we are missing standards for what happens during the transaction and what execution looks like and many other things and I think that the the the end game for these uh startups is going to be is going to be around modular accounts which is something I'm quite excited about and uh what's a modular account so with modular accounts uh in I mean there's not going to be one perfect account that fits everyone because people have different needs there are different features so someone wants say this kind kind of validation with that kind of spending limit and wants to have a session keys in order to play some game using some nft assets or whatever so each user is going to have its own needs so instead of trying to find to find one compromise One account that fits the user's needs the the user should treat the account as the this is the user's device the user's operating system on chain and even if everyone uses the same operating system or or even more than one so if everyone uses the same operating system it doesn't mean that they run the same apps on it so I I see modules as apps and my vision for it is that eventually we're going to have like app stores you have like you have an app store where you can install different different modules for validation and for a for execution for many other things even DB specific modules like modules that improve the ux of specific DBS there are now two standards uh there there are two standards working on it from different direction there's a ELCA uh 6900 and they are another one is a 7579 and each of them is taking a slightly different approach but I think they're going to end up in a similar Place creating the user's operating system on chain and letting the user install modules just so we can uh chis off to add stuff to too but just just so I have a better visual understanding of this thing is a modu or account a subset of a smart account or a superet or is it a is an instance of it where does it fit in with our definition of just what a smart account is so um a modular account is a smart account it's implemented on 457 so both of these standards actually are ERC 437 accounts but they add the hooks they add hooks in order to run certain things and a way to define what like they Define interfaces for what modules or plugins look like so it's a so in a sense it's a subset but I think this subset is going to be very important I think that like many of the many of them are going to be uh are going to be modular and uh we have to and uh we have a safe here so safe so safe head modules for a long time it's uh so modules the idea of adding modules to the account is not new so I've did it before I think that having a standard for modules so the different account implementations can share the same modules and having a definition of how the model interacts with the account what it can or cannot do so you can safely install it and know what permissions it ask for so you know just like uh you if you um if if you're using your phone and you install some app I mean you need to know what the app is going to do so it cannot take over your phone so same thing for for your account so I think that extending the standard for modules uh it's going to bring a lot of interesting use cases your original question was is account abstraction solved and the answer is definitely not right actually we're we still there's still so much to build and there's still so many problems to solve so you know some examples there's quite a few but some examples is just DB compatibility with smart accounts now if any of you are building DBS in the audience please for the love of God look at uh ELC 1271 um take a look at you know there's many libraries which allow um you to verify signatures from Smart accounts please use them please please use them I've come across some so many apps I've tried to write an article on mirror XYZ for example could not do it on a smart account uh many many other examples please if you're building a Dap support smart account signatures there uh other problems like you know high gas fees right so with um 437 the validation of transactions happens on chain onchain smart contract this is more expensive so we've been working at PCO for instance on how can we compress the qual data of user operations making it cheaper for end users to actually um interact with you know onchain applications through SM accounts um there's other compatibility issues right how can you very easily you know do things like request session keys from SM accounts there's no standards for that right now they are being made as we speak but nothing is finalized how can you make it easier to do smart count SSO right logging in with smart accounts and choosing Which smart account provider you want to use So currently there's many examples of people embedding smart accounts into their applications but there's been a pattern which I've been seeing which is you know every time you go to a different dap it actually creates a separate smart account for you so your identity your assets are all in different places depending on what what application you're using right this is still an unsolved problem well there's there's many eips elc's like ELC 7555 which again try to standardize this try and reduce the fragmentation we're seeing with with smart accounts so no absolutely not solved I feel like uh the SDK layer actually is doing really great there's been a lot of very different sdks from different teams who've made it very easy to get started with smart accounts but there's a lot more to do when it comes to standardization right getting these remaining L um annoyances out from developers allowing them to really make smart accounts just as easy to integrate and use for end uses as normal EA accounts now that that actually is super helpful to know cuz effectively it's talking about we kind of know how we want to do this thing but we just haven't collectively agreed upon what is the right path for it um one thing I guess I'm also curious about is does anything change for how econom traction works on ltu specifically or is it just mappable everywhere exactly the same um are there any nuances so uh L2 L2 has been the focus from day one because the ethereum scaling strategy is based on actually pushing users to L2 so a account obstruction 4 7 was planned for that but there's a but on L2 you could have a higher higher efficiency for example as Kristof mentioned the gas efficiency is not great and a lot of it is because uh a lot of it is because we had to implement the consensus part as a smart contract and that costus a lot of gas overhead so different l2s started working on a native account obstruction and uh that's that's great that's a they're actually so there two such chains already and both of them implemented a version of 4337 they are based on the same validation rules but they implemented it in different ways that are not compatible with each other or with 4337 and we started seeing fragmentation started seeing great wallets great wallets that work on one chain but doesn't but don't support another H one example would be Argent for example so it's um so so the next thing we should do is standard I standardize a way to enshrine account obstruction on chains that on layer tools that want to enshrine it and it's rip 7560 which is essentially ERC 4537 but instead of having entry point it adds this logic to the protocol that's the so I think on L instead of it being a smart contract we're making it part of the the VM yeah instead of having a single ton a Singleton smart contract that handles this logic it should be handled and it makes sense because I mean for EA the validation logic is known to the protocol valid account validation is important enough to be part of the protocol it should be the same for a for account obstruction validation and uh that's uh so that's the next thing for H for layer for Layer Two got it uh maybe kind of my my final question here is just overall obviously we know there's a lot of uh still open questions here for making AA a lot more simpler but uh where is kind of your time going uh for you as part of the F and and for you as part of Pimco um where do you kind of are spending the time here and improving this and um what can we look forward to so on our side um we feel like obviously there's always things to improve on the infrastructure side that's actually been pretty stable pretty usable for um developers now so we're focused a lot on the developer tooling side of things making it easier for existing devs who built their uh applications with things like wagm VM you know all these popular dap building tools to migrate to Smart accounts or to get started with smart accounts from the get-go right I we feel like that is um by far actually the most uh High leverage thing we can be doing to try and make people switch over we're also quite focused on making the standards that I mentioned before things like session key standards things like smart account SSO standards U move forward and actually get to a finalized stage so we can really have these final roadblocks removed from um the this usability yeah so I think uh tooling is a so tooling is really important and we're going to see a lot more of that and standards for the higher layers um standards for for the higher layers as Kristoff mentioned a few and uh I think we're going to see a lot more of that then uh on the lower layer there's the native account obstruction we talked about and I think the end game for account obstruction is that it becomes it becomes native in a standard way across all of the across all of the evm chains including ethereum that's going to take a while but we're working on it and uh there's and there are many uh many challenges to solve that are like more technical in nature for example uh for example sensorship resistance so we we we made it as sensorship resistance as as ethereum itself but ethereum itself is working to improve sensorship resistance with things like inclusion lists and making inclusion list work with the cab ction is a pretty big challenge so there so we have this kind of projects and we're going to do a lot of of these in the uh in the next year awesome well yav Kristoff thank you so much for this chat and uh can't wait for Millions more account to uh to use Smart accounts and uh leverage account abstraction thanks thank you so much