Account Abstraction: Making Accounts Smarter

foreign [Music] gas station network but recently we're working with your Weiss which was supposed to pass this presentation but he's sick in the hotel so we are covering him up we'll talk about account obstruction and the what can be done with it first what is account obstruction but before we talk about his account obstruction what is an account on ethereum account comes in two flavors one of them is externally on account but we all know in the other are contract based accounts and if you have a wallet you're probably using an UI account UI accounts are very easy to start to work with but they have quite a few limitations first of all key management is very very problematic the private key is tightly coupled with the address which means you can change it you have to keep it secret because if you lose it you lose everything but if you make copies in order not to lose it someone can find it and then he will get everything and you will lose everything so Key Management is hard there's also there's one one fits all access control you can do everything it might be good for you for personal usage that you can do everything but it is very very limiting if you know a all these operations by abstracting them away we mean it is not the node that performed operation that checks the signature that checks the the security of the node check the balance perform the payment but we abstract it away and make a contract the wallet contract being responsible for all of these so the key management becomes simpler because the world can do a key management by itself a Access Control mechanism if we want the Gas payment he does a lot of things become easier but just the easiest way to think about this is making contracts while contracts first class citizens they're no longer second-class citizens of ethereum and that you don't need an eoa in order to operate your contract wallet right you can start from a contract wallet and you'll never need to have an eoa okay from now when we're talking about the contextraction now we're talking what can be done with it now with the next slide with all the features none of them are implemented by us they are about to be implemented by you we only open the door with accounts in order to be able to add all these cool features so the first use case is recovery right now the recovery sucks you can't recap your private key you can't really recover it you have to save this private key somewhere as a multiple funny words or otherwise with account obstruction you can Implement into your wallet social recovery or other recovery mechanism and you can add a Deadman switch like if I'm unfortunately or someone is about died and you don't want everyone to lose all the the assets he has it can set a Deadman switch that is after a period of time that he's not using the account someone else uh will inherit this account this I can multi-sake that your family controls but it only becomes active a year after your you know your your key is is not active yes we're talking about recovery but multisig of course when you're talking about a signature cases multisig is a uh something that we see we want to have for accounts another option is per device Keys you might want your phone your phone is a very strong Hardware to protect keys so it might be very easy that you know the protection of your phone whether it's fingerprint or whatever or other biometric check this is the way to control your account and if you lose this device yes we have recovery we use another I will assign another device as my a wallet signer a disappear device keys there are other signature scheme you can use BLS signature is a very has a very cool feature which can be compressed very nicely and which reduce gas on a L2 Networks so it's an extension that can be added on top of account obstruction on those Networks to reduce the gas fees and if you are looking into the future we know that ecdsa signatures sometime in the future will become weaker that is the attack will become stronger and with the quantum machines eventually within 5 10 or 20 years they will be able to be cracked we want to be able to upgrade our accounts at least our important ones before them Quantum resistant signatures might be a way and again each of those cool features we are talking is not a systematic change of all accounts is a specific account want to experiment or want to add a feature okay you upgrade your account and now you have those features like any of those on the slides around sorry dismiss anyone okay now we're talking about some roles you know you have right now as I said with EOS you have a signature and you can do everything when you use Smart account you can put roles you can allow different roles to do different things maybe on your home on your personal account you want to do the master to do it all but if it's a corporate account you might say that you want the legal department to be able to vote but not move tokens you want an auditor to be able to cancel pending events but not generate events is set to a I don't know set to a payroll system to be able to submit to known addresses again the sky's the limit what you can do and it is still you can add it to this account okay wait maybe a little bit about session Keys ah sorry okay we talked about the the high end of a account that is accounts corporate account there is also the lower end you know you have your personal account but you also want to play games with games even the single accept per request might be annoying you don't want to accept each operation so for games you might assign your account a session key this key is allowed to make transaction for specific Target specific game and now you are Wallet free you free the ux from accepting each transaction and you know it is limited it's only this game so it can be your own wallet but you didn't sacrifice for this game you're a nice security is this the next yes okay we talked about the security about the role access now let's talk about the gas gas obstruction with normal accounts the account has to have if in order to pay for the transaction with account obstruction we want to abstract away the gas we want to be able for a third party to pay for a transaction which is very very good for onboarding like adapt want to pay for transaction for is deployment of each client or client that uses its own account if you have a token it might be useful to use your own token your for the so the user will be able to pay with your dapps token for transactions and for Traders if a Trader want to trade on uniswap with a die why should he have Heath to pay for gas he has died why not pay with that so paying with token is a cool use case that we really want to have a in in the system a privacy if you think about it if you go and you want to protect this privacy and use a mixer like to another cache or other and yes you put the money in now we want to get the money out but you have to have gas in order to withdraw this amount how did you get that gas from some kyc account so you're not really Anonymous when you withdraw funds from a mixer you are not Anonymous even though you would like to be so if you're using a count absorption model you can use part of the amount that you withdraw from the mixer is a gas payment so this way you can withdraw and completely Anonymous from a mixer well one thing quick to add is the gas sponsorship model is very flexible um toll gave an example of onboarding where you're subsidizing the fee entirely but you can have arbitrary logic it's implemented by a contract you can limit that in any way you want you can subsidize if you want only some transactions you can make a user is authenticate in some way you can decide only to subsidize governance actions I mean it's arbitrary logic so anything you want you can do with this just you decide what the conditions are including asking for repayment in another token as I said all of these are features that you have to implement we implement the infrastructure I'm only suggesting a cross chain operation a since we are abstracting as we have a contract you have a contract that can pay for its own deployment and you have a mechanism that can pay for the deployment and for execution transactions the next thing to think about is that I want to make operation on multiple networks I am on first Network I can pay on there but I want to use my account on other networks so it is possible to create a paymaster mechanism a payment mechanism that I will be able to perform that operation on those and other network if you use my signature I approve these transactions so it's not some other party acting on my behalf it's me acting on those networks but I don't have any balance on it I don't have to have any if balance or native token balance on those Networks it's a system that can move the payment between the networks why am I keeping people moving back and lastly we have a wallet so there's a link for them for the entire presentation of the everything at the end uh as we said with the eoa accounts I'm limited for performing a single operation at a time which cannot be batched and cannot and requires a exception on each operation it's very easy to add to a Wallet account create performing a batch and doing atomically a sequence of operation another use case we can see that you want a Atomic operation or a delayed operation that is I create an operation and I want it to be executed later a service can do it and again it is my account that performs this operation because I gave some service the rights to do it at a later time uh okay these are all cool ideas some of them are very old some regarding just the event driven flows because they're very interesting maybe a couple of examples one let's say there's an nft that means at a certain time then you don't have to wait in front of your computer and then you just like create the transaction then you could pre-register the transaction into into a like a registry contract of pending transactions and then Searchers you provide them an incentive to execute the transaction when the time comes and they're competing with each other right now the use case would be let's say you want to perform some trade in the future or pending on certain conditions price um you know whatever whatever you want so all this becomes possible and doesn't require any Trust foreign okay with the ear three four three four three two seven uh we wanted to create an implementation of a counter obstruction that can be a executed today not something we have to change the protocol but something we can add today so we Define a mempool of what we call a user operation user production is a transaction in our terminology so just like the normal user a mempool of transaction there is the mempool of user operation that nodes can withdraw transactions from they collect them and is to send a to batch them and send them on the network but the key thing about about this separate mempool it's not a private mempool like flashbots it's just separate because it's accepting this this user operation um instead of a regular transaction but the key thing um that's different about this is just it doesn't require you to have like an eua to interact it doesn't require you to have the eth um the paper it because what you're doing is you're specifying within the user operation the conditions that will make it worthwhile for bunders to uh submit your transaction on chain um and they they make sure they get like refunded for gas um so it works out Okay so our implementation what it does it takes I said these user operations uh they know you no longer need an eoa to send this user operation the node themselves take the user operation collect them into batches and put them on chain perform the validation that is validation is the signature nonce and the payment and then perform the execution that you want to make a if you read the AP most of the AP is not about usability about how wallets work but how we protect the network it is very important that those nodes that handle operations like when they handle transactions are not susceptible to denial of service attacks so we had a lot of mechanism to make sure that they cannot be attacked so we batch them together so that they will be cheaper and they sending them on chain it is since it is contract based it can work on any evm based Network today where we we want to take it to the next level right now when you create a an account obstructed wallet we want to make it a first-class citizen on the network First Class A account on the network right now it isn't it is second class because there are some differences between UI accounts and some applications require eoa accounts in the way they work in the way they require signature think of permit you cannot do permit directly with a Wallet account we do want to make them first class citizens so the next stage after uh what we've done today which is having a contract-based mechanism to deploy them on chain we want to add them into the network to what we call enshrine 437 into the network so that account abstracted accounts will be account and transaction in the system just like normal accounts and then to make it possible to convert any eoa account into a smarter into account obstructed that is there's going to be a way it is not fully hashed yet it will take some time until we finish it and until it be approved into the network but [Music] there's going to be a way that you have a normal account and you want to have those uh extra features so you will be able to enable this account there are several ways how to do it one of them is that you will actively have to convert your account your account into a smart account abstract account the other way is that they're going to be some point of in time where all eoa accounts will become abstracted but with a default implementation that emulate completely the normal eoa account and from that point you can yes you can keep the same implementation or you can switch to a different implementation if you want a extra features like all of those that we described earlier so one one um um one thing to maybe refine a little bit is um we believe eoas will need to go away at some point um so right now they are enshrined into the protocol um and we've discussed some of the limitations around that so at some point eoas even if there's backwards compatibility they will they will not be a part of the protocol anymore um we don't necessarily think that it makes sense to enshrine any specific alternative like you know this is an ERC maybe there will be like you know improvements in the future because that could be dangerous but what's clear is abstract accounts are going to be enshrined into the protocol there are going to be there are going to be accounts that can do all the things that we discussed out of the box for new deployments and for older deployments so otherwise you would need to transfer all your assets from money away to another and that's very expensive and cumbersome and you know potentially risky so that's where we're headed and in terms of the implementation yeah like they all said there are various ways of going about it um to be determined okay what can we do uh you can start experimenting with a esc-4337a now I see people who experimented here in the hackathon and yes over there also a you can add useful features to your accounts innovate do whatever you like and if you find something that you think is good for the public you can apply for an EF Grant and they what they and anything building adapt as we said accounts wallet accounts are a bit different from UI accounts so even today when you're working with apps this is not strictly related to account abstraction but to Wallet account in general make sure that you are not forcing the user to use a accounts like if you're checking signatures there is an extension the 1271 that allows a Wallet account to check a signature because it doesn't have a signature by itself a Wallet account just to be clear we're talking about contract wallet yes yeah if you have a token you want to have permits be aware that permit as it is today in usdt and die does not support a Wallet account you cannot use it from a Wallet account but again because it uses the signature there are some other tweaks like TX origin and stuff again in general try to be supportive for wallet accounts because these are the future not only the glossy safe today but also account obstructed in the future and also if you're using gas sponsorship models should also think about it how to interact this probably will need an interaction between your application and the wallet in order to provide the ux how to provide is a to your users and and the last item would be regarding uh wallets if you're developing dapps then maybe um there's some space if you you find that well it's not supportive enough of a contract wallets then you can voice your concerns and and uh try to lobby for that as a as adapt developer that that really helps um um so you know getting everyone on board is is a is a process that um we could use your help on okay okay it is before the last the QR code is missing here so if you want the link to all these I can give you it but it doesn't appear on this version of the presentation any question yes so I have like two questions like one are related to how uh currently like account abstraction exists as of today as an implementation can you provide an example like how like it can be potentially used in a way as it is in present form and the second question is related to The Next Step like they're like uh curious about like smart contracts containing code then like is there a distinction between operation that involves uh the smart wallet calling its own code versus uh calling uh the code uh from a different contract is it like uh on code becomes uh like a proxy for uh other contract call while interacting with other uh contracts in that ecosystem okay okay for the first question how to edit account obstruction is an interface that a basic implementation that we have in our source code that your wallet need to inherit provide a method or two and then the contract wallet supports account obstruction there's also sample how we add on top of existing ignosisafe without touching the code adding a module to make it account obstructed enabled and you do need a wallet application or browser extension that will be able to use it we have the basic SDK how to write it there are several wallets uh Soul wallet described behind the behind you a demonstrated the hackathon and also a proton wallet a hackathon project that try to use there are no implementation in existing wallet like metamask doesn't support it right correct currently you have to use some other wallets but this is now in the work there are several wallets that are adding account obstruction support regarding how the call is done the basic solidity it's a wallet is a contract when when someone make a call it validates it is allowed to make this call that is either the owner or through account obstruction the validation method and then it makes a call outside so anyone any other contract sees this contract as the account that makes the operation like whether it's a token transfer or voting or whatever we have another question so regarding smart contract wallets um so can you can you comment on the situation on when you need to use L2 Solutions because in most of the cases you you cannot because you have a small contract wallet Deploy on mainnet and you cannot deploy it on the same on this uh um on on every L2 like arbit room or Optimus because it you know it's it's uh for instance sorry it will become a different answers that's what you mean so so you you will need to represent the exact the exact deployment to get the same address in order to do things like claims of course yes the short answer yes we built it in a way that it will create the same address so you can have the same address on multiple networks yes as a wallet developer it requires some work from you in order for that to be possible but it is not that difficult and it can be done even the minimals the the minimally implementation of that is happening when you just funding your wallet the first time think of it you open your wallet software you see the address it is not deployed anywhere you see my your address you go to index and you move eth or whatever into it and then you make a transaction with that wallet if you're thinking of it this wallet contract will pay for its own deployment and then execute yes that's how account abstraction implementation works today so it works any more questions thank you for your presentation um I guess we all agree about like the importance of account abstraction and this is what Luxo was working on like starting from 2018 and like starting with ERC 725 standard but and I was checking the the CRC like way before and like I couldn't understand because it was way like too complicated but I have just two questions like can you explain more about like how users can choose the implementation and about like the cross chain execution and just an open question maybe we can discuss that later like don't you think that the standardization of the account up like the account need more standard laser standardization of other stuff like I will give you an example if you have a like a your account needs to receive token it needs to implement on erc721 received on your c1155 received and token received for erc223 but like what if we come up with a new standard in the future like on we need on ERC 6700 maybe and like maybe also we need something related to followers or like I don't know why because now it's related to token now the hype is token maybe in the future it's not we can discuss that later if you want I'll try from the beginning yes there were wallet accounts before account obstruction they exist from the beginning of a ethereum which is not far away but they exist we didn't invent the wheel we created a standard which allows the framework which allowed nodes to support such accounts accounts to be able to behave as close as possible to your accounts like pay for their own deployments which would be tricky it's possible we we created one there we did standardize on a way to perform validate to separate validation from execution in order to that in order that they validate us what we call bundlers can be self-sustained and can be a dose protected yes the AP is complex but most of these complexity comes from these protection mechanisms if we should rewrite it in a way that is more account friendly because most people don't Implement a bundler they want to implement an account so they need to know what they have to do maybe some of the limitations they have on what they do and they don't care about the low level implementation yes editorial work is required for this uh spec I agree and they of course change the execution a cross chain execution let's take it off chain again nothing of it is in the core of the EIP like BLS there's no BLS in the core what there is in the core for example is the ability to do signature aggregation that you check the aggregation in one place for entire batch this is in the core BLS is merely an implementation of that we narrowed several interface you add another contract to perform it but it's separate from the core so it is modular all the features like specific feature of wallets you suggested some callback that exists today and maybe a callback that will exist in the future the wallets will have to implement them right now your eoa doesn't support them anyway the idea is that when you deploy a an accountability contract I'm not think it's even written in the spec but we expect it to be an upgradable proxy that the owner can upgrade and if it isn't a creative proxy we have a basic implementation and then the owner can change it don't don't you think we're sacrificing security if like we're going with upgradable what you do need to do is to make sure that on your first upgrade you upgrade it in a way that now you add security for example after the first upgrade you can only specific mechanism will be able to upgrade it okay account abstraction can be abused it is I will not prevent you from creating an insecure wallet I think you can create a secure wallet with it thank you your office your office is watching us and sending us uh sending us messages trying to participate in the question and answer session you've just said hey like uh what happens post validation is not part of the standard it's not part of erc4337 and anything anything can happen um we can talk about ideas on how to make it happen but it's not specifically related to The Standard that we're working on right now it's kind of uh you know outside of the core because we want to make the core as general purpose as possible because maybe we don't have all the best ideas yet by the way if you think there is a security breach and something we can add to this definition I'll be glad to talk and we'll be glad to edit we are overtime however with this is a break time so if you guys have lots of questions we're happy to yield them if you guys are happy to have more questions anybody else anyone else so how can you make sure that um you know a wallet a smart contract wallet will be able to prove that is for example only controlled by one individual versus multi-six such that the receiving contract can make a judgment call on whether it should reject or accept that call right so for example if I if I have right so we have we have a separation okay the model we have is like this a smart contract has a separation between validation and execution execution is anything it calls out you know you execute external content whether it's atone another validation gets the user operation and validates whatever it likes the minimum is validated signature and validate the non so that it's not a replay and it's a valid signer but it can do more it can check the actual executed method and say a okay I restrict access to this destination or if it's a complex rule I restrict access to this destination for this signer because I have multiple sign and each one has a different role and is allowed only specific method the Target contract like a token usdc token usdc token doesn't receive all this information usdc received transfer from a standard and it will accept it it is the wallet Logic the logic inside the wallet within its validation whether to allow or disallow specific the operation we are now trying to make did I make myself clear I'm not sure yes it is complex yes if you're if you're if your target smart contract does not have you know um additional computational things going on that that require it to for example if so take royalties for example right if I if I have if I'm if I can I can circumvent royalty payments if I transfer an asset from from from from Alice to Bob right uh um and and right now if I with an eoa I actually have to transfer the the private key to circumvent the the the uh the royalty payment if I allow a smart contract doing that I can change ownership of that of that of that of that no because the owner of the tokens is the Smart contract yeah I understand but the point is if I can transfer the ownership of the wallet address from a to from Alice to to you yeah that's exactly the problem so it's like it's like it's that is exactly the problem if you're in a royalty situation that cannot be so if you want a wallet otherwise just a second otherwise it's your circumventing royalty if you want and while you're doing something illegal I'm not saying it is I'm not saying that we support it I'm saying that a contract May support it for example if you want a soul-bound wallet that you can't transfer the owner at all right go ahead create such a wallet if you want a wallet that doesn't support set implementation then create a wallet that will refuse to change implementation once you fixed you reach that implementation you don't allow to change you can create such an implementation we don't block such an implementation but we support others understood it's just is there is there any standard way to to communicate what type of wallet implementation it is such that the the targeting contract can can check whether because you you don't know right it's like it's like it's like whether the targeting contract needs to know the context of the wall implementation to make a judgment call about the owner okay first of all target contracts out there in the wild don't know anything about the collar except that it is a message center they can check the code if they like but you are talking about the use cases that don't exist with EOS so they really knew also for us smart contract calls for any operation you're talking about the other thing you talk about standardization how to know uh yes it is required we are providing right now the infrastructure for account obstructions for wallets to be built about on top of it standardization between the account contracts and for example the wallet application that use them something that the the ecosystem will benefit but it doesn't exist yet because neither the wallet nor the nor the contracts exist today so usually it will be a siled like a given application with a given a a given wallet contract with a given a UI ux for it but we won't we will try to push and try to find Innovations from the from the community to support such integration in such a apis your scenarios are interesting but I don't think they exist at all in the ethereum ecosystem the short answer is an nft can just check the code of the color and if they want to restrict uh you know themselves the Primitive wallets they can certainly do that it was it will this all of this will happen in a layer above what we're doing did you all have had some questions that he wanted you wanted to present it I'm a proxy for you right now are you guys okay for a couple more or okay oh hi uh thanks for the talk I believe you're also an author of eip2771 uh is that right uh yes okay this is basically self a meta transactions and with open GSN yes so yeah I was just curious uh what you see the role the role of eip2771 having in an account abstraction world and also for those who don't know it uh just explain it a little yeah it doesn't it doesn't just not needed because I don't need it anymore open GSN tried to do a gas abstraction which we later implemented into account abstraction for existing eoa accounts and the requirement of the gas station network and network of three layers which are the actually standards of transactions meant that the Target contract being token or other couldn't tell the real sender so we they had to be modified support eip2771 at the method so that it can tell the real sender which is a pain it's it because adaptation of this requires the Target contract to be changed doesn't support existing tokens for example if you want your token to be meta transaction enabled you have to rewrite it so yes it was problematic it was good for dapps to add support for existing users to sponsor the gas account obstruction they has a Much Higher Goals to replace the accounts and it supports almost all existing contracts as I said with the limitation of contracts that limit themselves to EOS it supports any contracts on the Chain all tokens for example so we yes with the limitation you need to add support for some tokens in your account that's right I agree so the target here is not helping adapt building the account obstruction though you can do it the target is letting the user have control of his own account and do it in a better way thank you George do you have another one what I mean last one maybe thanks um so I haven't looked at four three three seven so it might be like a basic question but um how does like ownership of the account work like the abstracted account is it is it private key held so it's kind of like an externally owned smart contract account um is it single owner is it multi-owner uh and the other question I have is is this like a complimentary standard to off and off call or is this like how would that work with with when off call is implemented okay the answer for the question the first question is all of the above or any of them because each wallet can decide as I said we had a wallet here in that demonstrate how to use zero knowledge proof instead of signatures another wallet that implements the RSA signatures from your phone you want eoa yes our simple implementation uses in eoa is an owner but it's just one implementation the other question regarding Earth and Oscar it is possible to do some of the features with Auto and Oscar they basically do the abstracting payment we believe that it is far too complex feature just to justify these two op codes because they don't do anything else of the account attraction they don't change they enshrine the ecdsa for example so they can be combined they can be used together but we hope for other alternatives a huge round of applause for a Syrian drawer thank you very much thank you everyone thank you so much [Applause]