Account Abstraction (Ethereum Foundation) by Yoav Weiss

hey everyone so my name is your advice I'm a researcher at ethereal Foundation and I'm on a mission to eliminate EOS or externally owned accounts so I'm going to talk about how about how and why so what is account obstruction to understand the kind of suction we need to understand what we had until now and what's wrong with it so the so most accounts today are externally owned accounts also called the eoa and these accounts have a single key as soon as they have a single ecdsa key hard-coded to the account you cannot change the key you cannot make any you cannot have it any other ways and that's generally a problem because Keys gets stolen or lost all the time and if you lose your key if you lose your key or someone gets a hold of it then you're in trouble um it's also in a All or Nothing proposition if your key uh so if if you have the key you can do everything at the account you have full control and if you don't have the key you can't do anything there's no way there's no granular access control so basically in security usually we separate between authentication authorization but here we have we don't have this separation it's uh the authorization is is just a Boolean another issue is a gas payment with an eoa with an AOA the gas must be paid out of the account itself and so it's not a great it's not great for onboarding because you need to transfer it into the account you know in order to start using it it's also not great for privacy because it's not great for privacy because you need to associate your new account with an existing account by transferring ether into it and it's not flexible for uh for dabs because one one operation is one transaction for example when you need to perform a trade within lc20 you send one transaction for approve and another one from transfer from and it's impossible to automate any flaws because you have to you have to sign any operation in the account obstruction offers an alternative it offers us a way to to create a to create a flexible account where I am to have a flexible account where that matches the user's needs and for different users it can mean different things for a for a new user we would like to just give the same to give something similar to a bank account when you're using a bank account or using your online banking you are not you are not worried that if you lose your password you will lose your bank account you can always you can always call the bank and they would help you recover it so we should give them something similar and we we shouldn't we shouldn't expect new users to uh to write down 12 Watts on a paper and to keep them safe users shouldn't see cryptography keys because they don't know how to manage them so we need to we need to add devices to the account let's say your mobile device is a is how you control your account and you can have a backup device you shouldn't have to manage keys so a more sophisticated user it can be it can mean something it can be something different it can mean having extra features extra flexibility for example a you could have access policies saying that from your mobile device you can spend up to a thousand dollars and if you want to spend the if you want to spend like a double that then you can use a 2fa and if you want to spend it unlimited amount then you should go get your Hardware wallet your Ledger or something from from your safe so with the count of suction you can add this kind of flexibility but what's great is that you can have this that it can evolve with you you can start as a new user and have something as simple as you like and then and then later have something as complex as you like adding adding features by changing the implementation in place another thing it another thing it solves is that a gas payment becomes flexible basically any contract anyone can pay can pay for the gas it doesn't have to come from the account itself so the account could pay for its own gas or a third party could do it for example a dab could sponsor its user's transaction when it transact when the user transacts with a specific contract or the user could the user could pay with ERC with erc20 tokens and then and the paymaster will convert it automatically and pay with ether that's also great for a cross chain because even if you have ether maybe you want to transact for another chain where you don't have the native currency it's uh it's useful for privacy because you could have a pay master that helps you pay for the that helps you pay for the grass when using a new account so you don't have to associate the the new account with an old one and it's uh it's great for the apps the dubs can have dubs can have a lot of flexibility when using such accounts the low hanging Fort is of course batching so you can have multiple operations in a single transaction for example they say approving a transfer form flow becomes one transaction you can add them you can add a lot more things such as a session Keys which means if you want to if you want to use your to use your account with a game and you don't want to sign a transaction you don't want to sign every operation in the game while you are using your nft for example in this game then you want to give the key to your browser and the browser will sign on your behalf but you don't want your but you don't want your browser to be able to transfer your assets so you could add another key to the account which is generated in your browser and you say that this key is only allowed to transact with the game it cannot it cannot transfer any assets so then you get much better your X without having to uh without having to take a risk and since the since the operation can be done we separated authentication from authorization so the operations can be triggered by any by by anyone who is authorized to do it not necessarily by the owner it allows us to automate certain things such as recurring payments where someone charges you a monthly fee and they don't need to sign you to you don't need to sign it every time or you can check certain criteria such as to perform at the perform a trade of a to trade a certain token only when it reaches a certain price and you don't need to watch your to sit at your computer and wait for its price in order to sign a transaction instead you set the conditions in your account and then adapt or anyone else actually can trigger can trigger your account to perform the trade only if the conditions are met and why is it called account obstruction so that's not a great name it's uh the name was given to it by protocol developers not by users and was being abstracted is all the aspects that all the aspects of implementing an account which means the uh the authentication the cryptographic signature the replay protection everything the Gas payment it's all it's all hard-coded in the protocol so the protocol needs to be aware of it but with account obstruction the Protocol no longer cares the network doesn't care how it how it happens so it's abstracted from the network it's not abstracted for the user so for User it's a Concrete it's a Concrete functionality it's not abstract therefore I like to call it smart accounts rather than when talking to users it's a smart account it's not account obstruction and the idea of account obstruction is as old as ethereum itself vitalik wrote the first post about it in in 2015 a couple of months before ethereum launched and since then researchers have been working on it for uh for about nine years now which makes it a pretty much the Holy Grail in ethereum and it's uh it takes it's been taking very long to figure out how to uh how to do it right in the in the early days of account obstruction with some contact wallets we learned some security lessons that are worth keeping in mind such as the parity wallet that used to be the most popular one in 2017 and it got hacked it got hacked and later also a completely Frozen costing users a lot of money so we learned that the count of suction also has downsides it's uh it brings a lot of benefits and is worth doing but it opens a new kind of risk of a smart contract a smart contract bags so they need to be well audited then in in subsequent years research accelerated and in particular the quilt team did a lot of research on protocol level account obstruction trying to trying to move to move the ecosystem through a protocol to work out of suction using a protocol change we also learned that this is really hard it's really hard to get consensus on it and to change the protocol and we have a chicken and egg problem you can in order to agree on what the count of suction looks like and understand it it's safe we need to gain some traction we need to experiment but but on the other hand you can't experiment with something that requires a protocol change because you can't do anything until the protocol supports it so and in parallel we started seeing some practical practical approaches we started seeing wallets wallets that show what account obstruction can do such as diagnosis safe or a urgent they demonstrated things like social recovery and many other capabilities but the uh but they but they require the centralized relay in order to pay for the gas so there was some centralization risk here now in the past two years we started taking a more practical approach to experimenting with a with account obstruction with elc437 that's the idea is the to make it an ELC so you can start experimenting immediately on every evm chain and not wait for a protocol change um and so and in the last year when in the last year we started the we started also seeing some layer Tools in particular uh ZK roll-ups using a adding a native account obstruction basically taking the principles from elc437 the same kind of maple protection but applied to the protocol level and this started an ecosystem of new wallets that take advantage of this so what is erc4337 first of all it's a full account obstruction since we abstract every aspect of the account we abstract authentication which means you can use any signature scheme you like not just ecdsa so you can use for example any device that so you can use the you can use your mobile device that has a secure Enclave in science transactions with your fingerprint for example and we abstract authorization so you can authorize any so you can have any access policies you like we abstract the replay protections so you don't have to use an incremental nonce and it opens some interesting use cases in particular for uh in particular when it comes to privacy and multi-tenant wallets and it abstracts gas payments so any contract you can pay for the Gaza you can Implement any logic that does it and of course execution is abstracted which means that you can have things like batching and and things that are specific to uh to assisting certain dubs you can have them as part of the wallet um now all of this stuff could all of this stuff was also possible using a smart contract account before we created a standout but in a centralized way using a centralized layers and the key focus of the a key focus of the ELC is on being censorship resistant and a fully decentralized so there are no centralized components in the system is a it it's a it uses a mempool it's a network of bundlers so there's nowhere there's nothing centralized to be to be attacked and this has been like most of the work on this protocol was around there that security now in order to make it to make it robust there are also multiple client implementation multiple implementations of the bundler written by different projects with different in different languages which which is a similar strategy to what we do with ethereum clients and most importantly no protocol change which means that you can start using it immediately on ever on a on every evm chain and then and then layer tools can start can start adding it to the protocol level in a way that doesn't break compatibility for wallets and this week we this week we announced that it's available on mainnet and on okay all right thank you so we um we passed we passed an audit with the open Zeppelin and no critical issues are found we deployed we deployed the contract on ethereum and on many other networks both the main Nets and test Nets so it can start so you can start using it and there are already bundlers running running on these networks so it's all waiting for you and you can start using you can start deploying and using stuff on on any network now where I know of I know of several wallets that are in advanced stages of being built or even audited so I think we'll see some announcements about that soon and to make it easier for for everyone to start doing cool stuff using this we also announced the grant round the ESP the ethereum foundation is running an account of suction Grand sound so if you're building something something unique and interesting using elc437 you could consider applying for a grant you have the link here I will also have it as a QR in the last slide and where do we go from here so this is only the first step we don't want it to always remain just in ELC we want to we want to see things being done more efficiently at the protocol level and we already saw some layer tools starting to edit and on these layer tools we see an emerging ecosystem of of wallets with much better usability than we have on other networks so I think we'll see this trend continuing and uh and you know we see this trend continue we'll see more layer tools adding protocol level account obstruction and the fact that they will all use the same standout means that wallets don't need to worry about it as a wallet developer you don't need to think about how you support each Network you implement it once and it works and it works everywhere and by removing this fragmentation we allow we allow wallets to focus on having the best usability the best security having features for users so it makes it makes ux better for all of us since wallets don't need to uh they don't need to spend the efforts on this on fragmentation and can really focus on user value the end the end goal is to then goal is to come full circle and as I said I said we have the we always wanted to have a count of suction at the protocol level but it was hard to do so now we are so so now after gaining enough to action and starting moving layer tools to all the native account obstruction hopefully at some point we'll be able to move the entire ecosystem even including a ethereum layer one although this will take much longer this will take much longer to uh to figure this out yeah but that's the but that would be the end goal and I think I'm also out of time so um so I leave just a couple of minutes for uh for questions here and you have the QR here for uh you have the QR here if you want to look at the grant round thank you so do we have time for a couple of questions okay so okay yeah okay so it seems we have a a very little time for questions so if anyone wanted to ask anything uh so where exactly is the logic living for the account abstraction you know that the networks will validate that the transaction actually fulfilled so the logic is in the account itself the account is a smart contract it has code so you implement you implement a contract that has a validate function called validate user op this function this function looks at an operation and and says whether it's willing to accept it or not so you can Implement for example the signature scheme let's say you want to use the BLS on it you want to use BLS so you want to use any other form of a signing you can verify it there you can also verify the replay protection because the nonce is abstracted you verify everything you need in order to decide that you are willing to accept this transaction and then it gets executed by the protocol