AA Is Easy, if You Don't Care About Decentralization | Yoav Weiss - Ethereum Foundation

hope you're doing well this morning and I wanted to welcome our next speaker we have yoav Vice he's a security researcher with the ethereum foundation and his talk is titled AA is easy if you don't care about decentralization thank you right hi everyone so um you so many of you probably heard me talk about account obstruction before and usually I talk about um usually I talk about use cases but I I often get asked about the complexity of ERC 4337 and why does it have to be so damn complex so today I'd like to say a few words about that of course we won't be able to go into the full depth of the protocol but I want to give you a glimpse now uh before we start let me tell you a bit of a little story about a monkey so I have a monkey nft I really like it it's really nice it's a really nice monkey but uh it's it's worth a lot of money so I want to sell it and I'm asking myself why don't why do I need this uh why do I need ethereum this complex blockchain in order to trade my monkey it's just I mean there's like a complex data structures like Merkel trees we have a we have many Stak validators with slashing conditions and we have um we have a complex DHT protocol with a PE for peer-to-peer communication uh we have multiple multiple client architecture why do we need all that why don't we just use a centralized web server and get it over with well it turns out that the it turns out that the answer is that if we are serious about the monkey being my monkey then we do need this complexity a if if I was okay with a trusting some server operator who may decide to take my monkey or to prevent me from selling it to someone then I wouldn't then I would wouldn't need a blockchain but turns out that we value that the Community Values things like self custody and censorship resistance so with that let's let's talk about accounts so smart accounts are a uh smart accounts are basically smart contracts that let me Implement let me Implement functionality into my uh into my account my own channel presentation but there's a problem uh with an EA I can communicate with the network I can transact on the network directly the EA pays for the gas I mean I just sign a transaction the EA pays for the gas and stuff gets executed with a smart account it doesn't work that way and you actually need an EO you need a funded eoa that will sign a transaction H to pay for the gas and make a call into the account and uh that's a big ux problem because uh we we cannot require users to have both a smart account account and an eoa with a some e and then require them to sign to sign the each transaction twice once for the EA to pay for the gas and once for the for the real transaction H that's just a that's a ux that's not going to fly and we'll never be able to get the next billion users so there's a so with that uh there's the centralized approach which uh which is what some projects tend to use for smart accounts and it means that there is a centralized server uh the the server has a funded eoa that can send the transaction and uh so I send I send my transaction I send my operation uh to the server the server wraps it in a meta transaction and uh puts it on chain for me pays for the gas and I compensate it uh like later but um or may maybe I do maybe I don't now the problem here is as I said uh there's it's it's not really self- custody if I need somebody else's server to interact with my account is it really my account I would say not really it's not uh if I cannot use the account directly maybe it's not really self custodial it's not really mine it's only somewhat mine and uh some some people say that's not a big problem and in many cases it isn't until it is like what happens if the what happens if the wallet company uh runs out of it runs out of money it goes bu and stops paying its AWS bill so suddenly the server goes down and I can no longer interact with my account I'm stuck or maybe then or maybe they get they get a denal of service attack against the server and also I cannot interact with my account suddenly or maybe they just they work just fine the server works just fine but it's about their business model changes to extract me so they front run every transaction that has value and they are going to win 100% of the time I have no way to defend myself because they are actually the ones sending my transaction on chain and of course they can be um they could sensor me because someone cses them to do so I mean the server is operated by humans they can be csed and there's the issue of privacy because the server knows my IP address so it has my real identity and it sees all of my transactions and maybe it keeps logs and shares them with someone I don't know so having a centralized server uh is not very good for self for self custody now so let's try to naively solve this problem one way to do it is say let's have many servers what if the wallet company runs multiple servers not one well that doesn't change anything because the servers are still operated by the same entity so they would go they would go down together or they would Sor together or or front runit together so it's it's like one server so the next logical step would be let's make it a decentralized and incentivized network of relays and then uh and then it's no longer operated by one entity and uh problem solved well we try that with this is what we did with GSN with the gas station network and it does decentralize access but there's a catch there's um there's a catch because what if the account behaves inconsistently the account could H when in an offchain simulation the account would appear to be compensating the relay but when the relay puts it on chain it actually doesn't compensate because it can detect that it's running on Chain by looking at some environment op codes so he decides not to pay and now we are and now the relay gets griffed so we need to protect the relay against griefing now how can the relay protect it self we'll again try some naive approaches what if the relay uh what if the relay keeps a white list of known account implementations they don't grief it and they really only accept these account implementations so that's fine but then who gets to decide what what account implementation is legitimate and and says that everything else is not so it's permissioned in the sense that uh Innovation is now permissioned so instead what if we have a what if you restrict users we say you can use any account implementation but you have to sign in with your phone number so the server can identify you and then if you grief the server they're going to um uh they're going to block you so this brings us back to censorship because if they can block you for griefing they can also block you for any other reason so um what if instead we say We'll allow any we don't require usernames and we don't require implementations instead we keep keep a we keep a reputation for each account that doesn't work because of cibil you can you're going to have cibil attacks anyone any attacker can keep H Lo can keep spinning up more accounts and keep griefing the server so what if the server after simulating and seeing that the transaction pays it will use Flash Bots to submit a transaction and will not um so it will use Flash Bots and ask flb the flashboot relay to only submit the transaction on chain if it ends up paying so now the Dos now the Dos Vector moves to flashboard itself because the attacker is going to send a to send um an ongoing uh like he's going to keep sending transactions that behave inconsistently so they all pass simulation get submitted to flash Bots but then flash Bots starts then flash Bots ends up not including them because they don't pay because they revert instead so after a while the flashboard relay that is now doing a lot of unpaid work is going to block this uh server which brings us back to a sensorship so now the entire server gets sensored so without taking all of these things into account we cannot build a we cannot build a robust and permissionless solution solution either it has to be permissioned or it's going to be vulnerable and be taken down by someone either way we don't end up with a sensorship resistant uh solution so that's what that's what ERC 437 aims to solve it's ERC 437 is a to is a account obstruction without uh account obstruction without compromising the centralization which means that there are no centralized components nothing is permissioned in a network and the account is fully abstracted which means that account that account validation uh inv involves involves the executing evm code and this enables this enables many attacks it enables it it can lead to many denial of service vectors which we need to address so the protocol has to uh the protocol has to take care of all of these requirements or else I mean if any of these requirements is not met we're going to end up with a network that that can sensor users or with no network at all because it will be attacked but if we can make it if you can make the network uh have all of these properties then we end up with a robust with a robust solution that we can count on and not have any sensorship vectors so how does ERC 437 achieve all that uh the first thing we had to do is we had to separate validation from execution the transaction has to be structured in a way that uh we know what part is the validation and what part is the execution and then we can leave limit the amount of work this is really the bare minimum we have to do we have to limit the amount of work that has to be done in order to validate a transaction if we don't do that then uh if we don't do that then the server May the the server may end up doing a an infinite amount of unpaid work and never get to do any paid work so we can say that uh even if the transaction is 5 million gas it can only use 200k of a gas to H for validation and this limits the amount of H of potentially unpaid work but that's only the start of it now we need if a transaction is valid in the M Pool it gets propagated in the M Pool which means that every node in the mol perform some work in order to validate it then we need it to also be valid with high likelihood to be valid on chain because otherwise again we get a denal of service Vector so for example suppose I Implement an account that has a that has a check for block number and it says if the block number is even I'm going to accept the transaction if it's odd I'm going to reject it now we have a so now during simulation during an odd block during an even block it will it will be successful so it will get propagated the mle but then when someone tries to put it on chain in the next block it's going to fail and not pay so we needed to prevent that in order to do that we um we had to ban to ban all the environment op codes during validation know that it's that all of these restrictions are only in validation during execution you can do whatever you want because you're already paying for it but until you pay for the transaction you cannot look at something like block number you don't really need block number in order to uh to validate any signature scheme so that's one uh type of restrictions another issue is a mass inv validation by flipping a flag in storage what if I have many accounts that uh if I have many accounts that all check a flag in some Singleton contract and then I send 10,000 transactions to this H to H to these to these accounts but then but I front run my transactions with one transaction that flips the flag and invalidates all of them so now at the cost of a single s store a single state change I invalidated 10,000 transactions and I caused the every node in the M Pool to First have to process these transactions and not get paid for them in order to prevent that we needed to limit the storage access but storage access is useful you need for example to access your keys uh in order to validate them so the account is is allowed to access its own storage and its Associated Storage which means storage that is associated with the with the accounts hash in other contracts such as an erc20 balance for that account but it means that uh it means that two accounts cannot access the same storage slot during validation which brings up the cost of the attack to order of n now you have to write to n slots to do n s stores in order to invalidate n transactions another issue is the the transactions cannot be mutually exclusive because otherwise I can have many transactions all of which are valid during propagation but when you try to include them bundled together in the same in the same block they invalidate each other for example U so I mean they could invalidate each other because during execution they can actually access anything so what if transaction one passes validation and then it and then during its execution it flips a flag in the in the in the account account of a transaction two and now transaction two that was formerly valid becomes invalid so you can send you can send any number of such mutually exclusive transactions and the block Builder will never be able to produce a block to prevent that we have to run all validations before any execution so the transa so even if it even if it's going to revert later because of then it will it will revert after paying uh we have some Global entities in the system that do need sometimes do need to access sto the same storage slot during transaction for example pay masters the pay Master the pay Master pays for the transaction for multiple transaction multiple accounts and it needs to access the same slots uh in this case it in this case we need to have a reputation for it so if it causes too many invalidations we're going to throttle it and it will not cause a lot of unpaid work but this requires a Cil resistance because otherwise someone can keep spinning up more uh more pay masters so in so the if the pay Master needs to access its own storage it's like a global storage it has to be staked the stake is not slashed in any case it just it's just used as a Cil resistance mechanism so I'm going to skip a bit because we're running out of time um now why do why does it have to be a standard why do all why do all the bundlers need to implement all the bundlers in the M Pool need to implement the same restrictions and not come up with their own protection the answer lies in a the answer lies in spam protection the net bundlers need to nodes in the main pool have to protect themselves against against spam against some against nodes that keep sending them in valid transactions so uh because this consists of this this is a unpaid work for them so if one node considers something to be valid it propagates it to another node that considers it invalid it will have to block the first node as a spammer so if they don't Implement exactly the same rules uh the network will get fragmented different parts of the network different implementations will block each other and we'll end up with many small mols now that's a problem because that's a problem because many having many uh smaller M Pools is much more prone to censorship uh to censorship attacks the it's a smaller group of uh I the transaction ends up in a smaller set of uh nodes and uh also it means that we lose the benefit of multic client architecture currently we have many bunder implementations but if each bundler implementation H was using it had its own mut with different rules it means that a bug in one client can sensor transactions so um and of course we lose some economic security because bundlers are less profitable they only see a subset of the transactions so we have many reasons to have the same rules for everyone this H this keeps the mol more robust right so the solution here is to have a is to have exactly the same implementation on exactly the same rules for all implementations and uh we needed to do the same with ethereum because of the multic client architecture so ethereum has a very clear specs for the very very clear consensus specs and we do a lot of testing and fuzzing to cover that and uh ERC 437 does the same thing so just to summarize since we're running out of time uh we have a so account obstruction could be really easy if we didn't care about H about sensorship resistance which is exactly the same reason we use the blockchain because we do care about uh we could we do get we do care about these values so uh smart and smart accounts shouldn't have to care about decentralizing about that they should focus on user value so ERC 437 does it for them as long as you use binders that are compliant with the protocol and participate with the mol properly right so I think we're out of time so thank you right do you have time time for questions or no okay