ETHWarsaw 2023: Michał Sieczkowski, Archblock - Breaking Down ERC 4337

okay so I already had a chance to introduce myself um so um I've been this in this space since around 2018 building deps mostly and during this time I have seen um many projects try to attract uh large audience and none of them in my view has succeeded in that blockchain apps are still very Niche and bizarre compared to uh other internet services that uh we use like PayPal or Twitter they are nowhere near the adoption of those services so in my view there are um many reasons for that and one of them is the difficulty in uh onboarding to the to blockchain systems so uh in this talk I would like you to take on a journey into uh account obstruction and in particular uh ERC 4337 standard uh that uh aims to simplify user flows let's see if the remote works for all right please don't steal my secret code okay um a little agenda um before we start um I divided this talk into three sections uh first uh I would like to uh get you uh a little more ex excited about the topic uh and discuss uh new possibilities uh that are uh uncovered with uh aland obstruction then we will dive into the standard and try to explain it step by step um we won't manage to go through all of it uh today uh there are just too many things um but hopefully you will have a solid understanding of uh how it works um and we will finish of by listing what else is there to learn about it U talking about some pros and cons uh and also how far we are in implementing the standard um so this is the the structure for this talk now this is a workshop stage and I'm coming to you with a talk so um I would like you to follow one rule it's very harsh but I hope hope you will forgive me the rule is that you ask questions as soon as you have them I would like this to be more a discussion than a talk so so at any point in time if something is unclear please raise your hand or wave at me if I don't see you and uh uh we'll start discussing uh what is unclear and uh hopefully um make uh everyone uh understand uh what is going on okay so why should we care about uh account obstruction let's take a typical web to onboarding first and you are all aware of uh of this uh you go to any random website and you create an account usually confirm it via email and you're good to go you can post your first photo on Instagram or like a friends post on on Facebook right now for DBS it's uh a little more complicated so with first ask our users to download a wallet app because our browsers don't have that built-in yet so they need to download metamask then they need to create an account in the metamask store the seat phrase and that itself is a really a lot to ask um I to this day like don't have like a good strategy for storing my seat phrases uh I don't know should I buy a safe and put it there should I I don't know put it under under the carpet it's too much for me then you need to the user needs to purchase funds and transfer that to their account only then they are able to do the first action so initiate a transaction and then we ask them to learn how Gas Works let me just uh increase the sleep when ini because you have don't know about uh I'll address that in a sec um just let me make this not sleep so fast very good point and my of course the remote is disconnected okay yeah you guys uh notice very well that uh not only you need to start the seat phrase you also need to uh come up with a password to protect the seat phrase uh that is stored in metamask right um to address this uh that you um can you repeat uh for us okay I'm Alexander kov and my point is that uh you just generate SE frases and from SE fras generate uh private key and and maybe public key but blockchain don't know about you before you initiate first transaction step because on this step you just create an account but in your steps it's an another yes this is just a simplification um let's say from users point of view they have no idea about EOS or anything like that they just use some some uh metamask call it right for me my life very okay let's move on we will discuss EA contract accounts in more detail in a sec um okay so once they have funds in the account um they can initiate did the first transaction and we asked them to learn about gas so before uh previously it was quite simple gas price gas limit now it got super complicated and we try our best in uis to abstract it way but in my view metamask is still difficult for users so once they sent out the transaction they need to wait for it it needs to be confirmed you see that a lot is uh happening here so what is account abstraction account obstruction comes with a bunch of promises so one of those promises is that uh you will be able to uh log into the DB as you would into a normal website so social login let's say you log in with Facebook or login with Google um what else uh account obstruction would allow us to uh give users possibility to change their password uh private key in this case so in case they think that oh I may have been sloppy with this pass password uh with this private key I would like to change it now they will have the ability to do that um what's more uh we can uh provide them with a scheme that allows them to um recover their accounts if it's uh lost altogether so you can ask a bunch of friends to help you recovering your account which is social recovery um what else could we do we could uh um provide a a way for users to pay only with one currency if someone is uh on boarding into your investment platform uh to invest usdc uh into your protocol why would they care about eth right they only care about the currency they are transacting in which is for instance usdc sorry um we could also think about sponsor transactions so um having a way for app developers to pay for the execution uh of their apps um it may not be feasible on ethereum where transaction fees are super high but on other cheaper cheaper chains why not um what else we could improve our user experiences in batching multiple calls into a single transaction so users are still confused about the approv uh in year C20 they don't understand why they need to do that and uh we could abstract it away we don't need to explain them what is it for we can uh make this whole in a single transaction um and something that's probably more we could have services that take subscriptions like Netflix like so um your DB could uh be authorized to get some funds from your wallet every now and then um and you would be paying for that execution as well as part of the subscription there are many many other possibilities this problem aut payments because in real life we have PS it's it's not real payments it's like clearing payments uh not real payments and if you don't uh say service for this payment you can claim it back and then for you but in cryptocurrency we can we cantion you know it's like that's to far we don't have charge buck in crypto and some consider it a great benefit so depending how you look at it um okay so having account abstraction what we could eliminate from this flow that we walked through well if we used uh all of that we could stay with just just the those boxes that are not crossed out yes uh the point was that only orange boxes are uh happening repeatedly uh the the the red one and green ones are one time set up yeah that's uh that's true uh and uh I put put the metamask in red because this is the the biggest step in my in my view in this whole flow who keep this Um this can be solved in many different ways uh let's uh go further and uh because this this is this is just a general idea for what is possible um okay so what you see here is nothing new you probably heard about it before you've some seen a project doing some parts of it and these are just a few of the top of my head uh starting with uh a project that um the company I come from did uh uh a couple of years ago and S set it in 2020 due to skyro skyrocketing uh gas prices which is unil login um all of those tried to achieve the same goals using a bit different methods so uh today we we will show you what is the latest thinking about solving those problems okay and uh what is account abstraction um what in my view account abstraction is used for uh nowadays um so I think it's a set of it's an umbrella term for a set of proposals uh that can be divided into two categories um first category are proposals that require change to the ethereum protocol uh and the second one that that don't now we all know that ethereum is getting crowded uh it's increasingly difficult to uh coordinate uh a change of protocol we we saw how how long it took to uh switch from Pro of work to Pro of stake um that's why I believe that uh uh the proposal that that don't require um protocol change is most likely to uh to succeed in the future just to give you a glimpse of what what those other proposals do so EIP 374 um was about supercharging EAS to have more capabilities and uh EIP 2938 uh was about allowing smart contracts to initiate transactions as I mentioned we're going to focus on uh EIP 4337 uh which is about creating a separate uh transaction system that runs parallel to ethereum and integrates with it nicely obviously okay so let's dive into it before we talk about about uh uh the specific specifics of The Proposal u a little recap um we have two types of accounts in ethereum U there are externally owned accounts controlled by your private keys that we mentioned and there are contract accounts well contract accounts uh are nothing else but but smart contracts they are governed by the source code that they get deployed with what is important is that only EAS can initiate trans transactions currently this is uh limiting in a sense that uh uh a of struction was hard to build before right okay so let's uh spend a minute to talk about why EAS are bad so you download metamask uh set up your seed phrase and create a bunch of accounts um basically having a seat phas is a single point of failure if you lose it you lose access to all of your funds and they cannot be recovered if you have the private key you have unlimited capabilities to what you can do with your funds you can uh transfer arbitrary amounts uh without any limits um also if someone steals that steals your seat phrase or private key uh they can steal anything so pretty much much Unbound possibilities now smart contract Wallets on the other hand allow us to um define flexible security rules so uh one of the most popular is multi6 you can uh protect your account with a bunch of uh private keys so this is something that you're probably very familiar with with contract accounts you could you can create those transaction limits or recipient white lists uh for instance you only ever transact between um those those couple of your accounts and you only use this protocol why leave a uh empty not empty but open door for um transferring funds any anywhere else you don't need it so you can start thinking about transactions and as you why list um addresses that you um interact with uh and not uh allow uh for anything um you can also Implement uh Social account recovery that I have already mentioned and this is cool enough uh that I wanted to spend a bit of time here so very simple scheme again it works this way um you have uh the private key to your wallet you are the only one that can um operate it um if you lose it you have a bunch of uh addresses set up of Guardian addresses this can be your your friends or your own account started somewhere else uh somewhere safe and you can use those addresses to rotate your main private key hopefully this gives you um and what I haven't mentioned yet is that uh in order to change the guardian addresses uh you need to issue a transaction and wait a couple of days so hopefully it gives you this leeway before let's say someone steals your your laptop and you know about it you have a couple of days to react to to rotate your keys and protect your assets okay so sure W oh um yes I think Argent wallet implemented that um a while back and that's the only one I have from the top of my head right now okay um I would still Advocate having this decentralized right so that's mhm yeah yeah so all of those capabilities with smart contract wallets is like you can use them now but not conveniently which you'll see in a sec um and uh I'll show you what is the goal of this proposal in the first place so let's start introducing some uh code that we will um wrap our hands around so this is the simplest um contract wallet it has a single function that uh executes arbitrary operations um in this execute function what it does it first authorizes the operation so checks the signature for instance and then it executes it so what is this user operation struct that is passed there think about it as uh a transaction in ethereum it has very similar Fields like the recipient of the operation uh the data field in which you encode what method you're uh invoking and with what parameters for instance um the value field which says how much uh e you're transferring with that operation um if the data field is empty then and and value field uh has some uh has some number then it's just a simple if transfer right you are all uh aware of those things so why do we have [Music] signature here uh very good question so this is uh a struct that uh is passed to execute function uh the wallet needs to uh be able to authenticate this operation this EAS uh it's a it's a normal uh uh EC it's a normal signature verification scheme as you would do with uh transactions um that would be true if you were the only one to send it and we'll see a sec that it doesn't need to be um okay maybe I can give you like another example of like a real life example of uh of this scheme so the way G safe works is basically like that it has an execute method that takes some user operation and in this signature field you would pass multiple signatures so for instance if you are a three out of five uh multi seek it would it wouldn't be a single signature it would be three signatures uh just to because the the signature Gathering happens offchain and you pass everything in in one in one transaction on chain so this is very generic for for now don't stick to any one um let's say um anyone uh interpretation of that and yes exactly so um if you didn't have announce then someone could uh look at uh the data of a previously submitted user operation uh and submit it again so for instance you submitted an operation that transfers uh one if from your wallet to some other wallet if you didn't have announce then someone could just do it again yes thank you for helping out um I'm not sure I get your question m MH okay you're going one step further so far um I'm talking about um uh us submitting the transaction transaction ourselves so this will be become clear in the next slide maybe um let me just explain a bit um so this is the status quo of using those smart contract wallets think of this part as your gnosis safe you still require to have you're still required to have a separate externally owned account to operate the is safe um you rra this operation that you want performed on the on the smart contract wallet in a ethereum transaction so what does it mean to user on boarding it means that they need to uh still set up the metamask account they cannot use the the smart contract wallets on its own at the back please very good question uh the signature here is validated validated by by the smart contract it has it knows the rules uh how to validate this transaction so for instance if this is a safe multi it knows the set of configured owners and it can check that the signatures that came were actually from those owners yes yes exactly um the whole thing you see here is a single uh ethereum transaction so um yeah calling the wallet and then wallet calls for instance another contract in a single AUM transaction okay so let's go further because you'll see how we could uh improve this scheme so I mentioned already the problem you still need to have a separate uh uh externally owned account to use your smart contract wallet it's not like a standalone wallet at all so what we want to achieve is this scenario where user uses only the the smart contract wallet and uh uh I'm going to uh base the explanation on a great article by David philipsson um you could have implemented uh account obstruction yourself I recommend it a lot so what could we do to get rid of of the uh separate externally own owned account for starters we could ask someone else to submit our user operation uh on chain so this is exactly what we do um we find find an Executor that will cover the transaction fee uh and execute the operation on our smart contract wallet uh on chain as part of this execution our wallet needs to refund the executor so that so that they are not uh doing that voluntarily um and this would be good right so now every time we we need want to do some operation on our wallet we don't send a transaction we send an operation to an Executor that does it for us this is some something that we uh discussed uh in a just just a second ago now this has its problems unfortunately and uh the first problem here is that uh the executor needs to be sure that they will get the refund if not uh they would need to trust the wallet that uh they will do that that they will refund them it's impossible to ask them to trust the wallet because you know anyone can have their own implementation of the wallet that's not verified on ether scan executor would not be going through uh each smart contract um and uh trying to figure out if they will not be cheated so what they would end up doing is they would try to simulate uh the uh transaction uh before issuing it on chain to make sure that they get refunded now this is problematic because um simulation does not perfectly predict the future simulation is run in the context of some version of the mle and uh what the mle will be is determined by the block minor right so uh to simulate transaction means to take the latest state of the blockchain and execute it locally on your machine okay you can simulate a transaction in a vacuum so you have some State until this block and you just simulate this one transaction you can go further you can take transactions that are already in the M Pool and try to compose a block yourself um and simulate uh your transaction in the con context of that but you will not you will never be sure that you chose the same transactions and as the minor would and you don't have that certainty what is more you can be gamed you can um so so the transaction can read from start St that will change at the time of execution exactly this is the second point it can use uh an OP code that is uh only um predictable at the time of execution right so you you cannot know uh what time stamp the block will be even because this is determined by the minor in in a blockchain system sorry guys I need to reconnect for I will make my phone not go to sleep let's try all [Music] right for okay we're back um okay so this was the first attempt um we asked the executor to uh submit our user operation on chain this introduced the first problem that the uh executor would need to trust our wallet let's now think uh how to solve that problem well in blockchain systems uh whenever uh you want to eliminate trust you introduce smart contracts right so this is exactly what we're going to do we're going to to introduce uh an entry point smart contract that is uh a single tone it's a single instance for all of the wallets uh on the blockchain uh it is trusted in a sense that uh its source code is well known it has been audited people agree that uh it's safe okay and uh now this uh smart contract uh will have a method uh for handling our user operations let's go through what this method does it first checks that uh the uh the the wallet uh that uh this user operation is for has enough uh funds to cover for the execution of that operation they can do that by taking a look at the gas limit that was set in the user operation um next uh they call the execute op on the wallet keeping track of how much uh was used and uh knowing that number they the function refunds the uh refunds the uh executor now for that last part to work we need to introduce a deposit system in this entry point contract so again we cannot trust uh the wallet to refund the entry point in this case um we need to ask the wallet to deposit into the entry point first first deposit is happening before you can uh execute the operation right so you already see the problem it's like two things to do one thing doesn't sound good right uh that would be it yeah so I'm not going into this direction because we're going to fix the problem right but that would be it you would probably need an EA at the beginning to deposit from your your wallet to the entry point and only then you're able to use the wallet Standalone right very good point it defeats the the purpose exactly um we also need to mention the a new field in user oper op a uh which is sender so the entry point needs to know uh for which wallet the operation is so we introdu the sender thank you and this is how uh this scheme uh would look like on a diagram so now uh user ask asks the executor executor calls handle operation on entry point entry point calls execute up on the smart contract uh calculates how much gas was used and refunds uh the executor from the wallets deposit in entrypoint contract any questions at this point can you repeat yes exactly uh anything that uh like we need to agree on some type of interface and then uh anything can uh uh can be a wallet also bear in mind that the method signatures I'm showing here are simplified in the standard they are called a bit different they may have more parameters uh this is simplified to you know uh make this uh consumable in this explanation Okay so I think you see now that we have uh solved uh the problem number one let's remind ourselves what the problem with what what the problem was the problem was that the executor had to trust uh the the wallet that it will return its funds now they don't need to trust we have the entry point contact contract in the middle it will always refund the executor that's cool but we introduced to problems right uh the problem number three we already uh talked about is that the the the user needs to deposit into entry point first and the problem number two um is a new one so now the the verification of the um user operation happens in execute op method let's go back one slide so user sends their operation it's passed on through this contract here and the verification of this operation so for instance signature verification or uh if it's a multi those those fre signatures are verified it happens here it is paid for from this wallet's balance the executor gets always refunded so what does that mean that means that someone can send a bunch of fake user operations so they can impersonate US pass them to the executor executor passes them along this chain and they drain our deposited balance in uh entry point yes yes yes exactly so uh can you guys in the front hear the question from the back not really not really okay uh maybe not the question but the statement was that um executor um uh needs to still have uh funds in their EA to put the transaction on chain yes that's exactly the case they are providing the service for us so that we don't need to have the EA on our own um yeah they don't lose anything because they get refunded right we will talk about their incentives in a bit uh is the executor is going to can you repeat next slide okay uh okay so that that's a good point um would the executor be passing along uh the invalid like the user operations of someone um pretending to be you yes they would because they get uh a tip for that which we haven't mentioned yet but we will get get to that they are incentivized to provide this service they don't care who pays they are just they are just the relayer here right very good point okay uh no he will because if the execution fails it happens in this execute op uh stage and uh the ex is always uh refunded so entry point calls execute op it checks how much gas is used it doesn't care whether the execution completes or fails it just checks how much gas is used and refunds the executor uh okay so you're asking about number one here um the ento will simply the the fees are paid in E the entry point will simply see how much if this uh wallet uh has and uh it will take the uh gas limit field from the entry point from the user operation and calculate based on that yeah huh yeah that's very that that's the answer uh because up until this point guys see point one happens in entry point it's a safe uh well-known smart contract so you know what happens only when you call an arbitrary uh contract like in so execute up in this case at this point you cannot simulate you cannot know what happens up until this point you know what happens so uh if uh the execution would would revert in the in the first uh step here the executor would not pass it on chain so yeah the executor uh these are all the details that you guys uncover during the stock uh this is very cool um I haven't even thought about all those possibilities When I Was preparing the presentation so yeah executor in this point at this point also needs to uh to simulate it just simulates up until the the first point right okay uh let's go further um let's uh take another attempt at this scheme so what we will do is uh we will extract validation from uh execution so we introduce a new method to the uh wallet contract called validate up and we will change the implementation of handle op in entry point so now what the handle op does it first uh calls the validate op uh if it fails you stop execution now now then it uh set aside sets aside if from wallet deposit into the entry point to pay for execution it takes the maximum amount of if that could would have been been uh necessary for the execution then again it calls the execute op keeps track of how much gas it uses uh and whether the call succeeds or fails uh the refund the the refund to execu the executor happens because we have the deposit system um in validate op we will um put only the validation part so we will authenticate this user operation so if you are a wallet uh for instance no safe multis in validate op you would put the signature verification and uh in exec up you would put the the the code that operates on the data of the user operation right yes exactly and execute op is protected which you don't see here it's protected in a way that only the entry point can call this and entry point call this method only in handle op method so execute op is not available to to anyone outside if you want to uh to do that you need to uh first call validate op you need to basically use the the entry point ex validation of the operation and then lockside the uh not really uh validate op only performs the the the authentication and the entry point contract uh sets aside uh if itself so the logic for uh setting aside some e is in the handle op function we're not pulling any funds from uh the wallet yet we rely on this deposit system so the wallet has deposit in the beginning but you're aiming at the next point which we'll get to to in a sec mhm let's see the next slide so what uh what changes here let's let's take a look at uh um it is it can be mutable yeah I think so it can be mutable but uh while okay guys let me explain so that you know everyone is following you guys are going ahead U so what we're doing with the scheme so far we extracted the validation part to a separate function and we will restrict the function in its possibilities we will do that uh in order to enable simulations that are reliable so let's now talk a bit about that what does it mean to make simulations reliable so first of all you will um in validate op you will only allow it to um call wallets Associated Storage so for instance wallet's own um own storage now how does that help uh it helps in a way that uh if you uh if you were an attacker you would try to to make the simulation fail in execution right so for instance uh let's assume that a user operation um like multiple user operations depend on one Oracle Val value if you control uh that Oracle value you can invalidate multiple uh user operations during execution so they all simulate just fine but then right before the execution you uh uh um change the value so that they all fail so that would be possible if we didn't have this first point here if we restrict that uh then the attacker would need to uh basically set this storage multiple times and that costs and so this is a a basically denial denial of service protection you don't need to understand exactly the the next two points this is just to give you intuition and uh the second large point is that you will we will forbid uh those uh op codes that are unpredictable in simulation so now that we have that let's take a look at what changes okay that's a very good question so the the executor provid a service for us they can choose what uh user operations they work with if they see that the that the user operation does not follow the rules they just discard it yes yes it happens on the executor implementation level exactly yeah you can look at the bite code to see if those OP codes are used or you can also try to simulate I think in in in reality they don't like analyze the bite code they probably just simulate and uh if that is used then uh exception and you know that's it okay so let's go through this uh scheme now what happens here the user gives their oper to the executor they call that they wrap it in uh transaction call handle op uh before they do that they uh simulate validate up uh now this is important because the user wallet will only pay for this part for execute op validate op would be charged to uh the executor so they are responsible for making sure that they don't pass invalid user operations on chain they we have restricted validate op so that they can run reliable simulations if they still pass invalid user operation on chain it's their own fault they lose lose e right uh after Execute op entry point refunds the the executor okay so maybe I have two questions so valid is run twice one in Sim exactly yeah uh yeah and second question when it comes to applications and infrastructure is it like in a single application like EXE HTTP appc um can you like try to rephrase the question okay um I think I I get what you're asking for so U this scheme is developed uh separately to Applications so application developer does not need to worry about that about that that will be implemented similarly to how blockchain nodes are implemented so there's a single or a couple of implementations uh like G parity there will be a couple of implementations of this executor that run the same protocol that we are just describing here um and the users of our applications will be then communicating communicating with uh nodes of those uh executor okay any other questions for this slide okay I think this goes back to who pays for what uh the executor only would pay for validate op if it failed right if something fails in execute op it is charged to the wallet so this can be Unbound this can be hard to simulate the executor doesn't care it's charged to guy uh we have pretty I'm halfway through the presentation we have time okay we'll cover that later let me go back to this okay so uh with this approach we have solved problem number two uh let's remind ourselves what was what was the problem number two the problem number two was that uh someone can um exploit the system by sending multiple invalid operations that uh would be uh charging from um users wallet now we have extracted validation to a separate function that is charged to the executor and they can easily simulate it hope you guys uh agree with me let's now solve the problem number three so you already pointed in this direction that uh now that we have this validate op extracted uh and it's constrained it's easy to simulate we can also as part of this function ask the wallet to provide if for execution so the wallet doesn't need to deposit anymore to the entry point beforehand during the validate op calls call uh the user wallet will transfer enough if for the execution it will transfer the max amount of if that would be needed for the ex execution now you can be asking are we refunding the the wallet at the end of the execution from the entry point but do you guys think can we refund the wallet at the end of the execution uh let me rephrase the question as like after after this step like during this step the wallet pays for the execution then this happens we spend some some eth and probably not all of it can the entry point simply transfer the money to the wallet back you're talking about re-entrance exactly so we are again executing unknown code so we we cannot rely on that uh and we will we will not we will simply um use the pull pattern right you guys know that if you send if to an arbitrary contract uh then uh a fall fallback function can be called which can fail use too much gas like an unpredictable amount of gas or even try to attack you via reentrance c as you just said right so instead of doing that we will uh simply leave the money and at the entry point and uh the wallet will be able to withdraw it later or it can be reused for future operations so if that's just a small change then the user will not care it will stay in the entry point and can be reused in the future so from his point of view it doesn't matter whether it's deposited into the entry point or uh or is staying uh in his wallet that's why this parameter is called required payment it's not called um max execution gas or something like that because some money is already deposited into into the entry point the entry point only asks for um if that's missing right to to cover for the maximum execution uh and boom we have solved the third problem with this uh system we don't need to deposit beforehand user don't need a separate EA now mhm you're saying that EA still needs to create the wallet in the first place re by okay uh typically in order to deploy a smart contract you need to um send a transaction from EA to create it right we're not going to uh cover it today unfortunately because we don't have unbounded time uh but uh ERC for 337 came up with a solution to that as well so unfortunately not today but you'll see that mentioned on the next slide um yeah we we already touched a bit uh on that so up until now executor was a volunteer like they were refunded but no one paid them anything for their simulations or maintaining their end points to listen for your user operations and integrating with the blockchain this was like a thank thankless task so we introduced a uh model similar to how we price our ethereum transactions uh user operation can specify um Max uh uh max amount of if per gas unit they that they want to pay and also can they they can separately specify how much of that uh of that fee should go to the executor this is purely like a copy paste of uh EAP 559 oh that's a very good question I'm I'm afraid I'm not super familiar with you all the details of GSN yeah uh so the idea is that the U you can find a third party to pay for your transaction instead of paying it yourself but I'm not really familiar with the details it's called gas station network if somebody wants to look it up exactly this should actually go onto the slide where I showed you the the pro the the projects that were aiming at solving account abstraction this was an earlier attempt at this problem basically okay we have achieved the goal uh that we were talking about so let's do a quick recap uh users can now uh use their contract wallet as primary count so instead of transactions they are sending their user operations to executors executors pass them on chain uh they get paid for execution uh uh from if that's stored in the wallet or already deposited into the entry point uh and we also have a way to tip them to incentivize them to to pass our transaction faster uh and so on right um the question is can this scheme be let's say generalized to use any tokens not e right mhm yes this this uh unfortunately it's not as easy as just changing the currency so the money flows that you are seeing on those diagrams uh it's not that easy but the standard has a has a uh way for doing that as well unfortunately unfortunately outside of the scope of stock sorry oh I not sure how that would work this is this is more about uh onchain action okay I think the question is uh in this flows that we described uh does the user contract smart contract wallet user need if in their wallet sit have like a so let's assume this situation there is a company like a real company it's web2 plus web3 I'm paying them with the credit card they top up my account on the smart contract of the uh relayer so they own the relayer and they store my balance my e balance inside of their smart contract and then theoretically if I just sign the transactions they could execute that on my behalf right so I don't really need to top up my account I don't even need to own an EA in the first place is that correct as long as I have a private key and I sign my transactions theoretically I don't need it yes that's pretty much it okay um we're nearing till till uh the end of uh talking about the standard um one important optimization that we need to talk about um so so far we've been talking about passing like individuals individual transactions on chain um and you already see that executor executors role is similar to that of a minor but miners don't do blocks of one transactions they do blocks of multiple transactions and this is exactly what we will do here uh we will bundle multiple uh user operations in a single etherum transaction uh this way we will spend save gas by not paying the fixed 21,000 fee every time um also it saves gas on Cold Storage accesses so when you access the storage for the first time it's more expensive than than if you do it repeatedly in a transaction uh so the only change we need to do to our uh signatures is in the entry point handle op is now called handle Ops it takes an array of user operation and this is how the diagram looks like pretty much as you would expect um and I would like you guys to to take a look at uh one important thing all the validations happen before all the executions can someone explain why is that the case sorry yeah so to answer the question first if you inter Leed first validate then execute then validate then execute then the first execute could mess up with the second validate right so the the stimulation would not be predictable again yeah yeah so what you're talking about is that uh the first operation could swap on on Unis Swap and mess up with the second operation validation right that's why we don't interleaf validations with executions valid uhhuh yes that would be the case if you allowed the validate op to read other contract storage but remember that we have restricted validate op in some capabilities so your uh validate op cannot read uh you know uh yeah so perhaps there are those side side effects that you will end up when you implement your app against this this scheme that you would for instance want to do something more in the validation that we haven't thought about I don't know I haven't implemented that yet uh what if the can you repeat can you try to again okay what I'm trying to find a loophole where I like we are bundling operations from different users right and I'm the malicious one and I want to make sure that my operations never validate somehow by changing my state maybe that uh in the next block it will no longer validate or something like this would it be possible for me to constantly mess with the um bundle so that it will never get through like I'm not sure if this is okay I think the answer is no because uh we have restricted validate op enough so that the executor can simulate it if the transa if the user operation does not pass the the simulation they drop it valid have have to transaction valid yeah yeah this explanation is very good U what what I can say to add add on top of that for instance can this validate mess with this validate so can first validate mess with the other one no it can cannot because uh we restricted the storage accesses so you can only access your own storage uh you cannot change let's say uh second uh operation storage you could be asking question let me say that you could be asking question okay so what if I S send two uh user operations of my own can can my first uh validate op mess up mess with the second validate op yes it could because it's accessing the same storage that's why there is an additional uh um restriction that a bundle cannot two operations from the same wallet it doesn't need to it doesn't need to access the storage uh for instance it needs to access its own storage to to know what is the set of uh multi owners okay guys uh we have 30 minutes let's uh move on so what I showed you here is that via a very simple change in our me methods you can now um accept multiple operations and uh bundle them together in a single etherum transaction this is why in the standard they don't use the word executor they they use the word bundler so I've been lying to you the whole time for gas optimization you you you do it basically to to save on gas so this is an diagram from from vitalik how he I wouldn't say this is the most beautiful diagram but this is how he uh sees that you have a mle of user operations submitted by different users you have a bundler that creates a bundle that gets included uh into a single transaction as part of ethereum block if you ever research l2s you start to see uh similarities uh here and there um and um we'll see another similarity on the next slide so uh finishing what else is there that we will not uh cover today um so let's let me start from the last Point aggregate signatures uh this is something leveraged by uh optimistic uh l2s already optimising cups um you can assuming the wallets uh use the same uh validation scheme so for instance they do a simple uh signature version verification you can bundle operations of uh different wallets that use the same uh the same um authentication scheme now if you if you have that then you can make use of uh a clever uh piece of cryptography called uh aggregate signatures so basically you combine multiple signatures into one and on the smart contract level you verify only one aggregate signature to make sure that all the individual ones are valid you're noing so you know the scheme okay and what else we haven't talked about pay masters uh pay masters uh is Again by introducing another smart contract to the scheme a clever way for us to instead of paying in eth pay in uh erc20 tokens or even have someone sponsor transactions uh we haven't talked about wallet creation yet but I would like to mention one cool feature here um the same as with EAS where you create a private key from which you derive public key and you know your address even before it is funded right here they came up with this the same uh property that you can deterministically know the address of your wallet before it's deployed to the network underneath it uses creat two op codes some of you may be familiar um now this is important because uh if you know the address of your future wallet then the user can pay for deployment of their wallet themselves from the start so you can create a a website where you integrate with some onam provider and uh they pay with uh uh credit card it's uh the the owner provided provider transfers uh some let's say usdc to um the future wallet address and some some bundler uh then uh deploys uh this wallet and gets refunded this is possible using the standard but unfortunately I'll not show it to you today like building blocks yes it looks like building blocks exactly I don't I don't expect them to try to uh let's say get in the job of ethereum protocol or anything like that last slide will be about that all right so how does that compare to how does the the design that we discussed compared to standard ethereum transactions in mle we can talk about some properties that are maintained so let's tackle the centralization first um bundlers are not uh some centralized actors anyone can become a bundler they operate a peer-to-peer Network public one just like ethereum uh mle so it's again sensorship resistance resistant in the same sense that uh ethereum is uh uh if your mle is sensorship resistant additionally if you ever for instance bundlers Are all uh against you you can still set up an EA and uh communicate with uh entry point on your own so you can uh send transaction to the entry point yourself you don't need to rely on the bundler worst case if if something happens right um I mentioned the wallet address predictability which is still maintained like with EAS and the last one I want to mention is that because we have the same fee model you can also replace user operations in the mle by submitting a new one with a higher uh tip to the bundler uh you had a question uh yeah so uh it's not the bundler is not incentivized to sensor your transactions if he does that then someone else picks up your transaction and and gains right uh we have a peer-to-peer Network so you can discover uh nodes right yes yes they operate a peer-to-peer public peer-to-peer Network just like ether miners do not nothing nothing that's the that's the whole point everything that you've s seen here is possible given the current ethereum protocol it's an EIP that does not require a heartwork we have solved the problem with smart contracts I find it very very entertaining not theoretically you'll see in a second all right uh what are the new benefits we already talked about it but let's recap so you have verification logic flexibility so your account is not only protected by a single signature single private key it can be protected by multi or social recovery whatever execution logic flexibility so EAS can send one transaction at a time if you use Smart contract wallet you can uh batch multiple operations into a a single transaction so this example approve and and swap for instance Unis swap um and another big one your wallet is upgradeable so it's upgradeable in multiple senses in a sense that you can change the composition of your multis wallet so change the owners of the wallet but you can also replace the logic of the wallet alt together right it's if you deploy the wallet under uh uh uh sorry behind the proxy using the proxy pattern then you can do basically whatever you want and that's a big one because uh you may have multiple assets and you you don't need to move those assets from one wallet to the other just to change uh uh your implementation right now what are the downsides um slightly increased uh attack Vector for do attacks so um hard to explain but in general in principle ethereum transactions you only verify one signature and you're done here you allow for somewhat constrainted but arbitrary verification logic so perhaps there is something that we haven't thought about and we can we are actually susceptible to some attacks and gas overhead this is uh where the fun stops unfortunately on if your M main net in order to create your account someone calculated that given using a standard implementation you would pay 300,000 gas let's compare that to EA zero you generate a keeper and that's it what about transfers uh simple e transfer 21,000 gas you all know that uh Inc 4337 88,000 what's interesting is that token transfers are not much more expensive as opposed to to transactions right uh I'm not sure if this calculation was already un bundled or not I I suppose that this was already on un bundled so this is uh well in my VI the biggest reason why we're not all using that already perhaps the other one is that implementations are not ready yet or or but I suspect this is also the reason um on ethereum Manet it's absolutely absolutely expensive uh given 30 uh gig gig uh gas price and uh now not not really up to date price of ethereum uh of ether it would cost $23 uh to deploy a smart contract wallet this way so this is a reason why previous projects like uni login uh failed because deploying a wallet uh cost like $100 when gas pric is skyrocketed we see the same problem on ethereum mayet here um so we should look to other uh other chains where it's more manageable and uh because this is all based on Smart contracts it's compatible with any evm chain we have talked about etherum but you can Port it to any other chain just as easily which I think is very very cool the question is if we have any Fork proposal that would make this scheme cheaper I'm not aware of that uh perhaps yeah and uh someone asked before about um implementations uh the these are just a few so a couple more um I haven't managed to you know track was there update was their status but um looking at the source code it's it's it's happening people are building that their commits from from uh a day ago or a couple of hours ago so it's coming that would be it thank you very much hope you [Applause] guys any closing questions uh yes I can uh I can uh send it to you later can the bandler force a sequence of transactions yes uh this is actually another source of income for the bandler uh meev is possible uh on user operations just as uh if your minor can order the transactions to to benefit them bundler can do the same it is complicated but people are doing that ethereum is dark Forest okay thank you guys again