ERC-4337 Account Abstraction via Alternative Mempool | Ethereum Foundation Talk

[00:00:02][Music] [Applause] [Music] all right can we start yeah okay hi so um so my name is joavis i'm from the ethereum foundation and and i want to talk today about account obstruction and the elca 4337 so first what is account obstruction account abstraction means it means that instead of using an externally owned account which means an account a directly associated with them associated with a private key you're using a contract to wallet and this contract wallet can be controlled by a key or multiple keys but it could also be controlled by an arbitrarily complex mechanism that is encoded in the in the contract so this uh this enables a use cases such as a social recovery which means that which means that if you lose you lose your keys you lose access to your wallet your friends can sign a special message with their keys to help you recover it or you could use a complex complex access control such as multisig in the context of your wallet it also allows you to switch to uh to switch even to different signature schemes such as moving to bls or the quantum resistant signatures in the future which is a quite useful for ethereum and it allows you to do things such as batching such as a batching multiple operations so for example for example let's say you want to trade an elc20 on uniswap you could so when trading you don't need to call you you don't need to approve and then to do a transfer from you can bundle both of them together in the same like in one call and uh so so this is a so a context action can be quite useful it can also do things like gas abstraction so gas obstruction means that that a decentralized application can pay for its its users gas it can sponsor it can sponsor so that the user can be onboarded without buying it this can be useful in uh this can be a useful in various scenarios and it also it also makes it possible for the user to for example pay for a pay for the gas with some tokens instead of having if and behind the scene the contract will trade will change the will change the token to eth in order to pay for the transaction so the user doesn't need to know anything about it if he has tokens and uh let's say you have a gaming application uh let's say i mean you have a you have a blockchain game something non-financial and the user doesn't own any crypto you want you want to onboard the users that are not crypto people so they can pay a service provider by credit card for the for a just for sponsoring their gas but this uh but this centralized this centralized service doesn't control the transactions it can't say anything about what the content of the transaction should be it can censor it it can only pay for the gas and it also it enables some more complex use cases such as having such as a private withdrawals from zika rollups and from zk uh from from like a zero knowledge mixers such as tornado cache currently if and accordingly if you want to withdraw money from something like tornado cache you need to have if in the withdrawal address in order to send in order to send a withdrawal call and this could be anonymize you because it associates an address that already has if with the others that's performing the withdrawal and right now they use the there are centralized solutions like a centralized relay that uh that helps you perform the withdrawal but then the really knows about you so with account obstruction this becomes this becomes a decentralized and it doesn't de-anonymize you because the withdrawal the withdrawal operation can pay for itself you can have a paymaster that looks at the withdrawal that looks at the withdrawal it sees that it sees that it's going to be successful so it will perform it it will perform the withdrawal for you uh take the take the cost of the deducted the course of the withdrawal and give you the rest which means that you end up with going to an address without associating it with anything else and it and it makes some interesting use cases that are very popular these days such as a cross-chain operations because it means that you could do things like cross-chain trades without having to hold the native currency of both chains so now that we see uh what what account obstruction can give us why why now why again ethereum already had its fair share of of account abstraction attempts there were many attempts to a to figure to figure this problem out and the problem is that it's very complex it's it's very complex and it's hard to agree because all of these attempts require require changing the consensus changing the protocol so what's different about this is that it's an elc it's actually there's no protocol change which means that it can be immediately used on any evm chain no need to wear no need to wait for a hard fork and this allows us to start experimenting with account obstruction without committing to a protocol change so we can start experimenting and iterating until uh until we see that we have something that everybody that everybody likes that satisfies all the requirements and there are no problems so um the end the end goal is to reach uh to reach a situation where we can drop eoa altogether we can we no longer need externally owned accounts and everything is account abstraction but in order but in order to take the first steps in the direction we need a way to experiment and elc 4337 is the way to start these experiments so this is our first step so how does it work instead of instead of using normal transactions we created a new obstruction level about above that which we call user operations and these user operations live in a separate mempool it's uh they live in a separate mempool and there are bundlers that there are bundlers that mine dismantle they take user operations they check that these operations are going to be uh are going to be paid for and then it they and then they send the bundlers they put it on chain through through a global free global contract called entry point which delivers it to the contract wallet and the bundle gets paid and gets paid for it now and this is permissionless anyone can be a bundler including the i mean the user can be can be its own bundler or anyone else can be but the natural fit is that it will be miners or post merge it's going to be block proposals or validators so uh um so the miners will probably participate in this additional mempool and we'll mine and we will mine user operations so so as we can see here uh users they just sign and assign user operations and put them in this user operation mempool where a bundler's bundlers take it from there and put it on chain as long as as long as they see that they're going to get paid for it so i'm going to go through a through the flow of such bundle uh from the moment it is sent to a it's sent by a bundler until the operations actually happen and starting with the simpler flow where there's no gas obstruction so the bundler so the bundler built a bundle of one or more op so let's say it puts some it puts some user operations inside the inside a bundle transaction it ran a simulation locally it saw that the boundary is going to be successful so it uh so so it puts it on chain sending it to the entry point now the entry point contract this is a this is a single tone there is one on the entire chain and this entry point starts by calling the validation function of each wallet so each wallet needs to implement a validation function and this function this function performs several actions first of all it does the access control which normally means checking a signature so it will verify the signature of the operation seeing that it is really signed by the user then it also checks for replay protection which in the current model means means checking a nonce and incrementing it and finally it pays for it pays the maximum the maximum cost of the of the operation just like just like it works for a for current transactions you first pay for the entire you pay the maximum cost and then you get you get refunded for the unused part so the so the validate function verifies everything then it pays for the operation and then the wallet and then entry point calls the wallet so calls the wallets to actually perform the operations so the opera so the wallets now get to perform the user operations to act upon the user's request and after that and after each operation the the entry point also refunds the unused the unused gas payment the parties that wasn't consumed by the operation gets refunded to the wallet just like with the current transactions now where now let's switch gear and look at the and look at what happens if there's a paymaster involved which means there is gas obstruction so now the wallet doesn't pay it starts it starts the same way entry point calls the and the entry point calls the validation function and the validation function checks the signature it increments the nonce but it but he doesn't pay it is not asked to pay because there's a paymaster instead the paymaster now instead the entry point now checks if the paymaster is valid and staked and i'm going to elaborate on that in a bit but let's assume it sees that the paymaster is valid and staked so now it also calls the validation function for the in the paymaster contract and the paymaster gets to look at the operation and decide whether it's whether it wants to pay for it if it wants to pay for it it approves it and now the and now entry point uh performs the actual operation tells the wallet it gives the wallet an opportunity to perform the operation and the paymaster is charged is a charge for the amount and now there's another optional an optional step here because the paymaster might want to might want to do something after it knows what after it knows how much it paid on behalf of that user for example if it's a token paymaster where the user where the user is paying with tokens so now the paymaster wants to charge the user to transfer tokens from the user to a to a charge for the operation so the so the paymaster could ask that they could ask for a post-op and in that case after the operation post or the paymaster's postal function is called so now uh so so now the paymaster gets to do its internal bookkeeping or to charge the user or anything else that it wants to do with this information so in order to uh in order to perform all of these duties the entry point contract needs to uh needs to have a few interfaces it needs to have interfaces to survey the three different entities in the system uh it serves the bundlers so the bundler has the bundler creates the bundle and it needs to locally call a simulate validation function which which is how it checks that the the band that the operations are valid and then it calls on chain the handle ops operation which which performs the actual which performs the the flow that we just seen and the paymaster paymasters have a stake as i mentioned so uh the stake so they need to manage the stake they need a way to lock the stake to unlock it and to withdraw it so this is so there's this interface and finally there's a there's a deposit that is used to pay for gas the deposit is owned by wallets or by paymasters so they also need a way to check their deposit and to uh to check the deposit to deposit more into it or to withdraw it so these are the interfaces that enterpoint provides and if you want to uh if you want to build a wallet to build a wallet or a paymaster you need to implement certain interfaces as well so the wallet the wallet implements a very simple interface it has just one function it's the validate user of function this is the function that gets called the that get called during validation it performed this it performed this signature check or whatever access control it has it has the it performs the nonce increment or any method of replay protection and it optionally pays for the transaction now the paymaster has a similar interface with a validate function as i explained earlier and it could optionally have another function called post-op where it charges the user will perform bookkeeping so the entry point is a highly trusted component because it's it's actually trusted by all the wallets to perform uh so it's a it actually tells the wallet what the user wants it to do so there so the wallets must be really sure that they will only get something that really came from the user and uh it's trusted by the pay masters to only charge them for to only charge them for operations that they really agreed to pay for and by the bundlers to compensate them properly for a for the bundle so um so there are a lot of security requirements i'm not going to i'm not going to go through all of them right now but we just finished a security audit with the opens airplane so the contract has been audited and and i'm happy to talk about the security later if anyone wants another important security consideration that also affects the way you use the system is the denial of service says the risk of denial of service against bundlers so um user operation user operation relies uh the validity of user operation depends on evm state and that makes that makes a pretty big attack surface against against bundlers for example if if someone can submit a large number of ops and then and then invalidate all of them at once it means that there's going to be a lot of unpaid work performed by the bundles they need to simulate all of this all of these ops each of these ops is going to fail simulation and get dropped off chain but nobody is paying for all of this extra work so we need so we need to protect against this and it can be even worse if there's a bad paymaster because the paymaster can a single paymaster can affect a large number of different orbs from different wallets so we put many mitigations in place the first one is a limit on validation gas so validation gas represents the risk the risk of unpaid work for bundlers and for nodes because this is the this is the work that's being done for the validation before knowing that uh that the operation is going to be paid so uh so each user operation has to specify how much validation guys it's going to need and if this number is set too high then bundlers are likely not to accept this your user operation and not even try to simulate it because it has too much risk another thing we needed to take care of is to make sure that the environment is consistent because otherwise otherwise user operations could be invalidated in large numbers without any action for example for example let's say we allow the during validation to check the block number so someone could send a very large number of ops that depend on the they depend on the current block number and they're all going to be successful when when added to the mempool but then the block number changes and by the time a bundler tries to bundle them uh the block number is no longer the the expected one so now all of these operations need to be dropped and it's going to be a lot of work so we so we needed to ban any environment operations so all of these all of the ones listed here are not allowed so an operation is not going to be accepted if it uses them during validation of course it can use them during the operation itself just not just not in the validate function and we also needed to restrict a couple of uh op codes so for example the the gas left the gas left call it can only be used in the context of a call when setting the the gas for a call you cannot use gas left to read the number and act upon it and make decisions on the gas in practice this shouldn't really be a limitation there isn't a lot that you need to do with it other than making calls and one last thing that we do to ensure consistency is we make a list we make a list of all the of any account of the code of any account that is accessed during this uh doing validation and if the code changed between between getting into the mempool and creating the the bundle then the operation is dropped without simulation normally this shouldn't happen it means that someone either created or self-destructed one of the contracts related to the operation so this is how we make sure that everything stays consistent which leaves us with just a storage access so we also need to make sure that a single storage change cannot invalidate a large number of ops because then someone could set a flag that kills that kills all of the of the ops in the mempool so we limited the wallet the wallet can only access its own storage it cannot access the storage of other contracts and this is complemented by another requirement that each wallet can have only one user operation in mempool at a time it can replace it by fee it could even replace it with a batch operation that for multiple actions but it can only have one so these two rules together mean that a wallet that a state state change can only invalidate one op it cannot invalidate a large number of ops um so we have a similar rule for a paymasters but for paymasters this is not enough because you actually could have multiple paymasters you could have multiple ops that use the same paymaster so we also needed a reputation system where each bundler maintains a reputation for for each paymaster it says and it needs to and it needs it needs a way to know if this paymaster is causing a lot of unpaid work so what it does is uh it checks it checks how many it checks how many operations with the display master fail simulation in a sliding in a sliding window and if it sees that the paymaster is causing too much unpaid work then it's going to throttle and eventually ban it for a while now this is uh and this is where the stake comes in because we needed a civil civil resistance mechanism so that it's not uh so that it's not cost effective for an attacker to spin up a large number of paymasters that misbehave so each paymaster has to lock a stake and if it wants to and if it wants to unstake it needs to wait it needs to wait for a while which means that if someone wants to perform such attack they need to spend to spend a lot of heath on deploying on deploying the spare muscles and each of the paymaster is going to is going to cause a very small amount of extra work before it gets itself banned so when can you use this uh we started building this eight months ago where it's a it was co-authored with vitalik and uh and since then the netherlands team and the opengsn team have been working on having a working on a building it and iterating uh and we kept iterating with vitalik on on the design until we were satisfied with it and now with a last week last week open zeppelin completed the security audit for it which allows us to uh to put it on mainnet so today it's available on ethereum net and on testnet it's also available on agnosis on gnosis chain formerly xdi and soon it should be available on more on more layer 1 and layer 2 networks and now and now is your part now we would like you to start building to start building and experimenting we want the computer the the community to start building elc 437 wallets and also experiment with different gas abstraction models by implementing paymasters so uh if anyone wants to start to start experimenting with it this hackathon is a great opportunity because the the opengsn team is sitting right here and could help you get started or you could join our discord where we can also help with uh such integrations and finally if you are [Music] if you are building any if you are building a cool project that uses elc 4337 you should consider applying for a for a grant from the ethereum foundation because we would love to we would love to see the community start experimenting with this right so um so so i'm going to post a couple of a couple of links for the for the eip itself and everything associated with it and now i would like to i would like to invite a draw from opengsn uh to a walk through the code of the sorry right so um so so i'd like to invite a drawer to a walk through the code and show what a wallet looks like what the paymaster looks like right or gsm still affiliated with it opens up not with open zeppelin it's maintained by is maintained by opengsn but it's uh it's active and it's active and actually a new version is coming on is coming out now i'm sorry you're asking yeah because open zeppelin was working on gsm right before uh in the first year in the first version we worked on it together but we've been maintaining it since okay uh just a second okay uh i'm draw from i'm from the opengsn team i worked on this project now after the overview of yorav i tried to dive into the two contracts in the system that interest you as developers i can overview the entry point but we don't have time for that it's the contract that we all trust and love and opens up a verified i'd love to go in person if you like but the two components that a applications will want to customize and create are a wallet and paymaster so first of all what is a wallet this is the interface that you have talked about a wallet is an account is a it stands it holds your account it has a execute function but we don't mandate its format so the interface doesn't require it at all and in order for you to easily create a wallet we created the the base wallet implementation uh it exposed nonce it has of course it has to have and the entry point it supports at any given point there is exactly one and it implements a valid user up so we provide you with the default implementation which verifies it called only from an entry point uh [Music] we have to provide a validate signature now the base this base doesn't implement it we'll see in a minute how it is and it performs a pre-fund which means it sends back to the entry point that called it the value the cost of this transaction [Music] if we go down into a specific the sample a wallet we created now sorry simple this is a very simple wallet and for one thing i want to zoom in great this is a simple wallet contract it's a it's a base it provides a nonce it has an owner and it accepts signature only by its owner it implemented the verified signature by using the verify signature it validates the signature using the standard ec recover if you like we can have any different signature scheme we're not enforcing we don't require any signature scheme not even a length this one uses a easy recover it uses a very very simplistic nonce mechanism which is increment by one again it's very good for start and it provides an exec from entry point which is of course how you it receive requests from the entry point uh it requires that it is called from the entry point to execute on behalf of the uh on behalf of this wallet which to create the request and one thing it doesn't do and of course a wallet is a probably will do it is not a proxy it works very well except that the deployment will cost you quite a lot because it's the entire contract is deployed each time you use it a better implementation of course will only deploy a simple proxy so that this contract can exist once on chain it also exemplifies how it uses a batch as you have said we can have only a single transaction per a wallet in the mempool but if you want more you probably would use a batch so we added a sample batch into this simple wallet and another example of something it can do is it can transfer it can transfer it from its own balance to other contracts and of course to execute code in any other contract it messif and okay and you provide the basic help function for luck it works only a it has an admin to modify its entry point this is the edge case where an entry port has to be upgraded so of course the owner can perform the switch this sample contract is also a access a standalone account a proxy account and it accepts requests directly from its owner that is you can either call it just like you would call any other contract object from your owner account or through a account obstruction where with the entry point executed as long as the entry point pays and as long as you're using ethereum as it is today there is no real difference uh as we said the difference comes when it when you use features like the paymaster so again if you look what it takes to be a paymaster this is the interface you have described earlier there is the verify paymaster a payment to receive the request just before it gets accepted and it has a if it appears in the request it has to accept it and then has a chance to run a post operation code to do it again we create a base pay master to implement to implement this interface it provides a convenient way to initialize the entry point and to support this entry point validate paymaster itself is exposed as it is because it's a view function there is no added value we can do in the base class but the post operation is required to be called from the entry points we enforced it in this base paymaster now let's look at an example which is it's very interesting but a little bit a bit more complex of a for paymaster this is a tokenpay master it is a token and it is a paymaster and if you have tokens you will pay for the request using it so let the the main function is the validation let's see what it does this is the validate usable it's a view function that a pay must expose and it should revert if it doesn't agree to pay and should accept if it agrees to pay for this request so it performs this is an abstract method a conversion from it knows how much this operation will cost so it knows how many tokens it needs to a request from the account okay it performs some validation that the the verification guys in the request is a big enough this security issue i'll not dive into it right now now we need to check if the wallet will agree to pay for the request what it does it checks that there is a balance that that the token balance again this payment is a token it verifies that the balance of the of this wallet is a high enough in this token paymaster and if this balance is enough and it reverts if it doesn't immediate balance is enough what you see here is its return value the return value of the verification is what we call a context it's something we pass after the request is complete to the post operation this is a signal from the paymaster to the system that it has some post operation to be done don't forget me after the execution i need to do i need to i need to complete the balancing of the user if you're going to this post operation it extracts this context which is the it saves the address of the user in the post operation it gets the actual cost so now it knows how much tokens it needs uh to get from the user so what it does it conforms a low level transfer again this is a token so it can do it by itself from the user's account to itself so this way the user paid in token we made sure that in advance that the user has enough tokens for the maximum possible price in token and post operation after the user completed the operation we perform the actual charge now if you are i think think maliciously as a user okay i will start a transaction and then the operation i will create is empty my token balance because if i empty my token balance after the operation i don't have any tokens and i will not have to pay anything the paymaster will not be able to charge me so we need to mitigate that now it's a bit difficult to see from this paymaster code how it is done so it is written somewhat in comments uh and you have skipped it in the first uh part when a paymaster runs its post-op post operation if this method reverts the entry point performs a very neat trick and that it reverts the user operation completely along with the post-op of course and then calls again the post-op of the paymaster now if you think about it the code that the user create executed was completely reverted it's not on chain so if you look at the state of the chain the pre-operation the verification the user has a balance was executed we did some operation and reverted it and now we call the post operation which means we have the user has a balance so if the user will perform this trick and try to empty its own balance the post-op will revert the entry point will call this a post operation again by the way with updated actual cost which is higher it has to cover for this revert and that sense okay and this and the transfer will succeed so this code it's not that complicated but this is a paymaster that works with a token there are several other paymasters we have in in the sample code i don't have much time but i don't have any okay okay if you like you can talk with us there is an one payments that we added is the ability to a kind of an oracle to trust an external address and so that this paymaster can trust a signature created outside of the system and outside of the net off chain and the payments will validate it and will pay based on this signature so we also think it's a cool paymaster to use and to integrate okay thank you if you have any questions any questions so yeah if anyone has questions there we can uh we can go outside because uh there's already available oh yeah i will publish i will publish it about this okay thank you [Applause] [Music] [Applause] [Music] you