Building an ERC-4337 Wallet: Account Abstraction Explained

[00:00:00]foreign [Applause] [Music] open GSN team we've done a lot of guys less and lately we're working on account abstraction with the EF ezr from the f and I'm here to describe account abstraction with a specific stress on how to build the wallet on this framework I will go with a brief overview of what the account abstraction is what we abstract uh security the architecture of a our implementation of a eip4367 some cool features we think can be built and should be built above it and then I will go into the SDK we have uh how to use it how to use this API to create a wallet uh we do need a knowledge both in solidity and ethers API in JavaScript I hope everybody here has it okay first of all before we do account abstraction as I said it's for doing for security what is the basic account security account security is for then there's a three things authentication replay protection and Dot protection those gas payments we're paying the other mechanism used by the system for those protection they're not just fines and when we say account abstraction what we basically abstract is all of these so we have a wallet a wallet is a contract and the contract can abstract the authentication it can do whatever it like replace the signature whether you can use ecdsa it can use a BLS for aggregation or other things to do Quantum resistance we as a counter instruction don't care what a signature scheme is used it except of using different scheme it can use to change the signer you're not bound to this sign address designer is separate from the account itself you can use multiple signer and a access roles whatever and you can do a recovery a lot of features you can do with a for Authentication for replift protection you still need to use somehow nonce you can use normal sequential nonsense like our sample but if you like you want to choose parallel that is transaction that can be sent on chain regardless of the order you can do it also and for payment yes you can do the normal payment the account pays for itself but we also provide an API to let an external contract to perform the payment opening cool features like onboarding where some external contract application pays for the deployment or using token paymaster to pay this token for transactions briefly the components we have for account abstraction first is the user operation this is our transaction the replacement for a transaction structure is user operation we'll see it lately later then there's a wallet the account which is built of course from a contract there's a center a second contract we call the deployer this is the contract that deploys new contract again through the system and the wallet software the ux we see the the browser extension or other software that shows the ux the transaction to the end user and let it sign the transaction it has to know the contract signature of course to sign using the right signature the next component or a system are the payments are the contracts that can pay for transaction if they want that is they verify transaction and decide whether this transaction is valid for their own payment system bundlers are the nodes that support account obstruction and put this a user operations a on a chain and the entry point this is the one contract we deliver that executes Unchained the transaction perform all the validation orchestrates all the system if we look briefly about how we add it to the system we have an application that uses the wallet software and send the RPC but you can see here that account abstraction doesn't come to replace say in one shot a normal transaction some nodes of the system continue to work with transactions some nodes no a normal transaction but also user operation user operations come from a separate mempool so when a wallet sends a user operation into some nodes and bundler it will get into the network yes we would like all the nodes in the system to support user operations and account abstraction but the system will work fine even if only part of the nodes supported uh if you look at the flow on chain once a node sends a user operation there's a single method in entry point called handle Ops to send a transaction the transaction goes through four steps first step if needed optional is to create this wallet if it has an init code it will deploy this wallet contract if needed once it is deployed the validate user method is called this is the main method we will see it later that a wallet has that validate the signature announced and everything and pays if they needed if there is a paymaster the paymaster is consulted whether it wants to pay for this transaction otherwise the transaction will be rejected and finally a the transaction will be executed on chain and as I said it's called handle opposite can be a bundle that's why we call it a bundler with multiple Ops in a single request but I will not stress of this because this is something that a wallet doesn't care about something that the system does for its own optimizations if we look at the transaction the way we see it is an application how how we add account obstruction how applications start to interact with it so an application is probably stay unmodified it uses a wallet it will continue to use a wallet the wallet will be modified of course instead of creating a transaction it will create a user operation and display to the user with the added Fields ask user to sign it and eventually send it to the node through a different type of SQL the send user operation the node bundler uh we'll accept it we it verifies it unlike normal node that knows the signature scheme and everything to check it it will it makes the view call to the server validate user up not directly but it makes a vehicle to the entry point to validate this user operation and it added to the mempool later on a bundler what used to be called in the past Miner will collect all these user production from the mempool and we'll create a handle Ops transaction and put it on chain okay let's see what we have in a user operation a user operation first it has all the fields that you see for you know from a normal transaction the call data itself got limit gas values signature and Loans except that the definition of nonsense signature are completely open to the wallet implementation then there are some extra fields that we add we put the sender since we can't assume this signature is ecdsa which you can recover the address of the center from the signature we have to specify the sender addresses specifically if the wallet is not yet deployed we have the unit code which is the code that is used to create this wallet and we have several extra gas fields that we have to add we have the verification step so we have a limit on the regards the simplification step can take and there's some gas value that has to account for all the things that you can't check on chain like call data cost the Etc and finally there is the paymaster information if there is a paymaster it will be specified on the paymaster uh what the wallet has a to Define the API we provide specify the function validate user operation in the iwallet interface this is the only function we mandate by its name by the wallet it received the entire user operation and the request ID which is basically a hash of this user version this is what gets signed and it needs to a validate the signature in aggregator not relevant for this talk it's for a separate talk about signature aggregation highly relevant for l2s not relevant at the moment and the missing wallet funds this is the Top-Up value the wallet has to pay if no one else pays and there is no balance that it already has it has to pay this to the entry point for this transaction to succeed if this valid user reverts the transaction will fail it will not pay anything if it succeeds then later on the entry point will call the call data there are two wallet there are two wallet specific functions we don't mandate their name but the wallet has to provide them one of them is nonce to return the current non's value when we create a transaction we need to know the current nouns and the other if the method that will be executed from the entry point so in our sample wallet we call it exec from entry point which I think is a good name it has to have implementations for these two methods um okay now I'm going to the client side I want to create a transaction I need to have a wallet but today we don't have a wallet that support account obstruction so we created a method where we can use an existing injected wallet like Mana mask and still use the account instruction with it um what we do is a we we take a the current we take your ethos provider the current provider you have we have an API to wrap it with a account abstraction specific provider when you send a transaction through this provider it will go through the logic of a create a user operation for it and to send it on chain so if you add this code to your client application it will go through a account abstraction one thing that is missing here is that you see we have the wallet address this wallet address exists even before the wallet itself is deployed on chain the wallet is able to pay for itself for its own creation so we need to fund it to send some if into this address or if you use the paymaster the paymaster can handle this payment but this address the signer address of our provider this is the address of the wallet itself and then I create a SSA contract and call some method and the method will get called and the first time the world is called this method will also create the contract the difference from a normal wallet yes it will take a little more gas because you need to deploy this contract just before making the call uh this is the high level API underneath this API we provide the we'd call a base wallet API this is the API that lets you create user operation you pass the parameter to it it will create a the user operation but creating use operation is a highly dependent on the contract so this base wallet API which is in abstract class provides four abstract methods how to create an init code for this specific wallet a method to sign the get nons this is the method that reads from a vehicle from the on-chain value of the current nodes and a method to create the execution function to make this call and in our sample contract we have a contract we call a simple wallet so we created a simple wallet API it it uses this a base baseball API and implement it for our contract double four methods so you create a simple wallet API and then you can call it a to create a transaction Center or unsigned transaction and then send it on chain the owner we see here also on the base class is a signer this is the the owner of the wallet which is the the class will get called to sign the this user operation uh okay if you have any question I can go back yes okay when you create a simple wallet API a specific wallet API it is for a specific instance you can pass it here the address I didn't specify if it is pre-configured you can pass it also the address of the wallet contract itself the apis I call it here is it is not yet created so I create this object I specify the sign the owner the signer and I have get a wallet address I have a method here to get the address of my wallet which will probably the one I will use on the next call yes the sample here shows only their first creation for an already created wallet yes you will specify the address of the world obviously also you can have it is possible to add account abstraction support for an existing wallet like we're going to sample how to take ignosis safe and to add it interface to be called through account abstraction so obviously if you didn't create it this way you have the address of the wallet it is not created through the system but once it is created you can use it let's try this yes both here and the high level API you can specify the address of the wallet yes sender it is called sender it is called sender because sender is the contract that we'll call the call data call data is the encoded call sci-fi and I will call it on the sender so I like to call it a wallet okay the same the wallet is the same naming is problematic yes what do you mean change the parameters and you can change yes yes we don't you can have what whatever you like I think the best way to do it is make a transaction that you as the owner of this smart contract makes to make some changes you can have an API that was only through entry point but if you want to call it directly for example you don't want to use for one transaction you want that the owner can also call directly this contract then you will want you will want that to change only and change entry font all this function will be callable the same way so this is the way we suggest to do it U.S owner allowed to make it's from this yes smart contract and also make changes on itself yeah yeah so I think the the normal flow for reconfiguring whatever whatever type of configuration you want to do whether it's to set a new entry point or even let's say it's a multi-sig and you want to add a signer then the the correct way to do it will be through a user operation where in the call data you can specify you can interact it's actually a self call the wallet is calling itself so it will still go through the same validation flow validate your validate user of implementation gets called and then after the wallet says yeah I accept this sign I accept this operation and then it will be executed on the wallet so we don't we we don't mandate which there's no interface for what other what uh what other functions the wallet needs to implement you can have an exit function you can also have configuration functions but you should make sure that they can only be called by the wallet itself or by entry point depending on the model you use not by anything else any more questions for what mm-hmm yeah yes it's uh you you would have to uh you would have to deploy if you wanted to have the same address then you would have to deploy you would you would have to send the first transaction on each of the chains which would deploy the wallet uh if you use the provider then this is a transparent to the user it just gets deployed but the caveat is that but all that both of the chains need to have the deployer in the same address in order for the created wallet to also have the same the same address it's a yeah it's done since uh it's all counter factual you can start so you can assume that you own the address you can assume that you own the address you can even send assets to it without having the contracts and then the contract gets created the first time you transact with it it's so it's created lazily or optimistically when when you need to start using it it's actually a it's an it's actually the way the way you're supposed to do it because the wallet is supposed to pay unless there is a paymaster involved so uh putting their paymaster use case aside the wallet needs to pay for its own creation so uh so you need to have uh so you need to have some if inside the wallet uh inside the wallet others before the wallet will even exists you send it to the address before after getting the wallet address and then when it gets deployed the first thing it's going to do is during the during its validation it will pay for its own creation and if it doesn't then the creation gets reverted yes and if you want to use it a cross chain a as a wallet Creator you have to make sure that the deployer contract is the same on all the chains and this way it will create the contractual address for designer will be the same on all Networks right yes we don't mandate how to use it but yet it has to be deterministic as you have said the wallet can't pay for its own creation unless you as a wallet Creator can counterfactually know the address and put funds into it so if you look at the high level API you see I I use normal ether the code I created the app provider the signer now provider it's not a real signer it's the component that sends it it's a user operation but it has the method get address in normal a account it is the account address which is really designed in our case it will return the counterfactual address that you can use to send funds to but again it depends on the deployer that will work yes we provide a sample deployer that is counterfactual that is creates the address exactly based on the basically it means that the deployer has to create the address based on the current signup the first signer you are using you have the signer or the component that will sign this a you create an old few in the next request of this wallet and based on the deployer itself and this address you a we create the address of the wallet if you later change the address it doesn't matter because then you will already have the address and you will keep the same address you don't care the counterfacturers only need for the initial creation that's wrong ah no no other no sorry go on creative yes so this is not a this is not a hard Fork it's an ELC meaning that we need the we need some bundle to support it and ideally it would be great if all nodes support it if all block Builders support it but we can start without it so we are starting a network of uh we're starting a network of of bundlers and we hope it will lay it will expand over time because it's going to be profitable for Block Builders so when a block Builder when a block Builder includes such a bundle in the transaction and the blog Builder gets paid for it so block windows are incentivized to participate in this mempool and include these operations it won't happen in a in a one day but it's okay it can it can happen over time I'm sorry I couldn't hear you right now right now there's an implementation of a nethermind that is a full-fledged node it runs currently on the girly Network and we have our own bundler and somewhat limited from a wallet's perspective it's fully functional it receives a user operation RPC and it puts them on chain from the bundles perspective it can be a dosable it can be a attacked large part of the ESC are made to how to make this uh network of bundlers resilient our specific bundler it's simple but it's not as resilient as it should we are working on it with Netherland and others yeah ideally functionality in an internal yeah ideally it should be ideally it should be part of nodes whatever when any node that is used for Block building has the information in order to in order to also build these bundles and as though mentioned there's a so never mind never mind implemented it in their own client and there is also and they also implemented it into Mev into Mev Geth so there's actually a get Fork that also uh that also supports this and we hope that we hope to see a lot more of those and uh another way you can currently you can currently run a bundle safely is by having it is by connecting it to flashbots or to Mev boost so that uh so you know that you cannot be you cannot be attacked in certain ways because you can use the protection granted by a flashbots to submit the bundle I think we provide the essential position resistance that the normal theorem nodes gets it's a mempool and the nodes take entries from the mempool that are profitable and put them on chain anyone you have actually another layer that if you have a specific application you can easily run your own bundler you know you will not attack itself because in order to be protected the bundler has to make view call to make sure it will succeed and mimic the transaction so a journal purpose bundler cannot trust a components not the front end itself but if it is your bundler you can always trust it so you can you have a way to make always your transaction but for a general use I believe it is sensitive resistance as nodes say clear on it yeah but there's actually you actually have a fallback uh but you actually as a last line of defense let's say all the bundles decide to censor you then and you're not running a bundler and everything you can always just put a bundle yourself since the bundle itself is just an ethereum transaction so if you have an eoa with gas you can use it to submit uh you can you can use it to act as a one-time bundler and put your you put your bundle on chain so it is a it is it is always a censorship resistant as ethereum itself foreign yes the overhead of the system is 20 or 30k or 20K on top of the normal 21k it's not a big deal you will lose because it's not a bundle you will send a bundle of one so you can't split it with others or if you do have you can it's less than a single unit swap operation and over it yes this is the simplest way to do it it is possible to manage multiple addresses but it's going to be very difficult to manage yes in order to be question you want to have the same address foreign itself it's a it's a use case that you want to support it do see ways that you can use the same address on multiple chains well it requires that you put the same deployer on all chains and then you have it uh this deployer can be deployed using create2 using some counterfactual deployers that are out there or using your account like the deploy of glossy safe is deployed by their own private key on all chains so they can will always be able to support a new chains so you can use that method once you use it you have a mechanism to have the same address on all chains but technically if you are if you are on chains where you can't have the same address I can see a use case for example for having a registrar like you know having suppose you have a Singleton contract where on the channel you where you initially create a wallet you could have a mapping you could have a mapping that says you can send it from a certain wallet and um okay yeah so you could build Solutions around it yes we added support for a signature aggregation mostly for BLS and we have a reference implementation of BLS using it the idea is that you send a bond a bundle of a multiple user operation but with empty sector in all of them as long as they use the same aggregator you have a single aggregated signature and there is a get another contract that you have to use which is called a signature aggregator you interact with if you want to go deeply I can we can talk about it later right now it is not deployed anywhere there's a sample that works with it but a we didn't go make any further progress with it yet yeah but it is only valid for l2s because there is a requirement that the cost of aggregating a single signature is a less and on ethereum the cost of pairing aggregating a single signature of BLS is more expensive than a easy recover so there's no point of using it on any chain that with the gas with the L1 gas limits on l2s where there is a huge gap between call data cost which is very expensive and the CPU that a CPU gas cost which is very low there it makes sense very much to be used yeah I think I think we are a bit over time so we can continue to take questions uh sorry if you want to uh if you want to keep discussing it thank you