New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

Mastering the API & SDK of ERC-4337 | Building UserOperations | ETHDenver 2023

Ethereum DenverMon, Oct 9, 2023, 12:00 AM

In this video, we delve into the fascinating world of ERC-4337. We'll take you on a journey through the intricate account abstraction system architecture and explore how it functions. Additionally, we'll guide you on leveraging the powerful API and SDK that have been meticulously crafted for generating UserOperations to seamlessly interact with the EntryPoint contract. Throughout the video, we'll unravel the complexities surrounding ERC-4337 and shed light on its inner workings. You can expect a comprehensive overview that covers all essential aspects of this innovative system. From understanding its architecture to learning how to effectively build upon it, we've got you covered. Join us as we dive deep into ERC-4337 and equip ourselves with valuable insights about this cutting-edge technology. Stay tuned for an engaging exploration of ERC-4337's capabilities! #ERC4337 #AccountAbstractionSystem TLDR: Account abstraction simplifies transaction validation and execution on the Ethereum network by using contract accounts, entry points, paymasters, and bundlers, allowing for batch execution, alternative execution mechanisms, and authentication with session keys. 00:00 📝 An account abstracted account simplifies validation, execution, and gas payment by using contract accounts, entry points, paymasters, user operations, and bundlers, allowing applications to create transactions that are validated by bundlers before being added to the Ethereum chain. 02:45 🔍 ERC-4337 wallets validate transactions through contract calls, verifying account code, paymaster, and gas before executing on Ethereum network. 05:29 💡 Account abstraction enables the validation and execution of transactions using code, allowing for batch execution and alternative execution mechanisms, while a paymaster contract extracts tokens from users to pay for transactions. 08:46 🔑 Account abstraction allows for authentication with session keys, which can be used for low-security mechanisms like gaming, as well as for corporate accounts with different signers. 09:52 💡 Different roles in a Dao can have different security mechanisms, such as token payments or sponsor paymasters, allowing for various use cases and the need to build. 11:20 🔑 A browser extension called Trampoline allows users to create and customize account obstructions with different signature check mechanisms, providing a user-friendly experience for onboarding and transaction handling. 13:20 📝 Account abstraction allows for the creation of accounts without the need for additional mechanisms, with the process involving providing constructor code, handling nons, creating an execution function, and using an onboarding component to collect user information and create the account. 15:34 📝 The speaker shows how to create an account, load source into metamask, and execute transactions in a custom UX, as well as connecting to a sample application on etherscan using metamask and mentioning the use of a bundler for user operations. Dror Tirosh ERC-4337 lead developer ERC-4337 core team (previously OpenGSN) Dror has over 30 years of experience in software development. In 2018 he entered the web3 space, starting as the lead developer in Tabookey, followed by the OpenGSN project, and finally joined the ERC-4337 core team

Transcript

an account abstracted account is a contract contract is the king what we try to abstract we abstract validation we have a account exposed validation method which allows us a different type of validation as we will see shortly we abstract execution like execute batch if you want something else instead of a single transaction and we have abstract Gas payment so that an account can pay for itself if it likes but if not it can use a paymaster contract it is a basic component of esc4337 maybe I should start with a small question how many people went into an introduction to 4337 okay just a few I'll keep it I'll continue we don't have much time for that so the main component we have is first of all there's the account the contract account this is the contract that exposed the account its address is the address you own and you control it and not only by signature but it could be by other methods uh the second component is the entry point this is the main component we have to orchestrate all the transactions to our accounts and as I said there are paymasters which are contracts which which are responsible for paying for the gas for transactions a user operation is the term we use for a transaction whenever you see the term user operation think of a transaction on steroid a transaction to a a user a to a to our account are called the user operations and under the hood we have a bundlers which are the block Builders to work with the memory pool let's see what it takes say the life cycle of user operation I as a user have an application the application creates I want to send a transaction to the network I use some wallet Contra wallet this is the wallet on my device a Chrome extension or whatever and I create a transaction a user operation just like normal transaction it is sent into a memo mempool is a member of user operation it's not a member of transaction but it behaves the same it is decentralized then a bundler one of the bundlers in the network just like one of the nodes pick up this transaction along with other transactions in order to create a bundle before it can put this transaction on chain you need to validate it with normal ethereum transaction validation is simple you validate the signature it's an easy dssi signature and you validate that it has enough gas but we as we said we abstracted all that we allow a lot of new things with our transactions so the validation is done by making a contract call it make a call a simulation called into the entry point the simulation call validates account the account code itself validate itself and if there is a pay Master the valida the paymaster validate that it indeed agrees to pay for this transaction once it is validated it is put into a a into a bundle a set of transactions that I put together on chain and we execute when we execute again the validation is done on chain to validate that indeed the transaction even when it's ran on chain accepts and pays this bundler and after it validates it performed the execution which is the execution of that transaction and then it put into the chain just like any other transaction the outcome of a bundle of the bundler is an ethereum transaction because one thing I didn't say is that the whole idea is that we run on ethereum network as it is we couldn't introduce a new type of transaction on chain so we introduced the mechanism of chain and a contract entry point and we submit a transaction one transaction on chain which is an entire bundle of user operations I I want to emphasize the difference between transaction and user operation this is an account an eoa account it is accurate asset but ecdsa mathematical formula to calculate the publicly from the private key to make sure it is correct it has a wallet the wallet can do exactly one thing approved it's going to prove this transaction and submit it on chain it is sent to the mobile to the mempool and then a block Builder put it on chain the mempool is there to make sure that the there's no denial of service nobody attempt to attack the network it is distributed all over so nobody can censor you the block Builder again verify the signature verify you have enough balance and add it to a block with account obstruction we have our account but account is a contract so the validation is its code it can do whatever it likes it will give server example later of what do we mean by validated by code what can we do the wallet again it's a software component but instead of only approving by ecdsa it can do many other things um then we use a mempool equivalent to the standard main pool to put it on and then bundles collect it perform the validation and put it on chain so in terms of incentives and the network flow it is quite similar to existing transaction except for the fact that we can validate it using code uh okay what is in an account what is an account contract I can talk contract we provide a basic account you see it's a single method called user a validate user operation which receive the user operation and it can validate whatever field they need from it the simplest thing it can do is validate the signature and validate the non so we provide a mechanism that validate the nons call a hook for the application to perform a signature validation and if need and it also told how much it need to pays if there is no payment it has to pay for the transaction by itself so it has to pay in advance for the max possible cost of the transaction in in case of failure it reports that it failed through the return value this is the basic account that we inherit this is an example of a specific account we provide in our repository you see we validate the nonce simpler we have a nonce we're incremented by one and we'll make sure that the user operation contains that nonce which basically replicates the a nonce mechanism that is used by eoa accounts incremented by one you can put another mechanism that will for example allow you parallel transactions and this is a sample validate signatures which uses open Zeppelin a signature check which again simulate a normal transaction normal UI account the execution method of an account that can has to be able to execute so it's a basic to received destination value and a call and it executed it is possible to execute a bat so also created a method to execute a batch and again an account can use other execution mechanism if it likes if you want to create a paymaster a paymaster is a contract that will pay for the transaction the simplest example of a payment is a payment that pay by tokens so when it its execution is a sorry when its validation method is called it validates that the user agrees to pay with tokens which means the paymaster extract tokens from the user transfer into itself it is called once again after the transaction is completed so that it can repay the user with the excess amount this again this is not the base paymaster it's a token pay Master which is a concrete example of a paymaster now what what can we do maybe you should start and say what can we do with that so I like the basic uh two examples uh for a authentication with account abstraction think of it that the ecdsa model is a one model fit all that you have to approve each transaction think about gaming when you're using a game you have a single or one or two Targets and you it's really annoying to accept and approve each transaction so you would prefer to have in your account something like a session key like for this specific destination for the next half an hour I don't want to approve anything the most will happen if my browser is compromised is one hit into the game it doesn't interfere with my tokens or anything else so session Keys is a kind of a validation that is used for a very low security mechanism in my account I will not use them always for games yes on the other end think of an account that belongs to a corporate a corporate account has different signers different roles like you know the legal are allowed to vote and allow to execute in a Dao and I don't know the CFO is allowed to move money and there is the accounting department which allows to put out salaries each one is different so you could have an account with different a security mechanism it's again it is a single account you can have different mechanism I want to I wanted to put several example of a pay masters here too I forgot to put it into the slide I gave you one example of token payments the other example is a what we call a sponsor premaster there's no it's not a specific example but think of an application that you want to pay for the users for your users if your user accesses your account even deploy its own account you want to pay for that it's small money and you want to attach this user to you so you want to pay for it you don't send money to the user you put a paymaster which will allow the user to use your destination so it's a specific kind of a playmaster for that if you want to see other use cases I put up a link we spent over an hour just explaining different use cases that you can do back in Bogota okay now we all Builders and we want to use it so and the main thing we need to build we need first okay we need to build an account to build a feature into it but then we also need to add this account ux to support it and so this is a a wallet a wallet a to support this a account so what we did we created the a boilerplate for a browser extension we call it trampoline because it gives you a jump start into uh you have QR code at the end with the link to everything trampoline is a sample a browser extension created by Health performance to grab it it is based on Tallyho that is a browser extension but it is tailored for creating an account obstruction with that if you think of a kind of something you want to do with account obstruction [Music] you can you can add it so I think let's say you want to add some different kind of signature check so yes you need to take you create an account so the best thing thing you can do you take a simple account or it's basically a space account and you replace the validate signature function now you have an account that uses a different signature check mechanism but it is not enough you need a ux to put this value in so you take the trampoline within the trampoline you have the account API and you add this ux into a a new trampoline the trampoline gives you a way to do some onboarding like collecting information from the user like if you want to find a clever way to use an email as a signature check it's great you will collect the user's email or whatever then when you handle a transaction this is why it will will be called to process a transaction and there's also a hook for mechanism you can use it only as for signing so the account API need to provide several basic methods it is called during onboarding the first is a create the init code like the Constructor call to create your account because part of the idea is that you don't need some other mechanism to create the account the account is created using account abstraction like with metamask you don't think if you never create an account it is always there it is never on chain but with account abstraction the first transaction to send usually is the one to create it from the account contract itself yes it means that the first generation costs a little more but other than that it's a normal transaction so you create the Constructor code for the trampoline to know how to use you need to provide it three more functions one is to handle the nons one is of course to create the execution function to create the signature which is parsed by your account and then during onboarding okay you have the onboarding component the onboarding component bring up a custom UI to collect information from the user and at the end bringing the hook say to create the account and if we look we'll see a transaction in a moment but a the user send a send transaction a normal send transaction from its application through a web 3.js or through ethers or directly to send a transaction this transactions is a is captured by a the wallet the trampoline wallet it calls the transaction component it can display information to the user and then when it completes the transaction continues it creates a user operation the account abstraction transaction gets signed and send on Jane a I wanted to bring a demo and it was appalling the status of the internet so I recorded one about half an hour ago okay so I start I open a my browser extension I disable developer mode enable developer mode because it has to be a developer mode and disabled metamask because it can't walk in together with the meta it replaces metamask and then I load the folder after I okay it didn't copy the screen I started the it locally and then it loaded the source into metamask and then and then it pop ups a screen it asks me to create an account this is still the trampoline creates and then the trampoline opens up a custom ux this sample uh didn't do anything in this custom ux away it's an empty screen and then it continue now it creates in memory the account the account is created he's in a it has an address and it's been update it doesn't have balance and it is not deployed on a network yet so a I don't have a payment so I switch to another account and I send some girl if into that account so I didn't have time to edit it so we'll have to wait in real time for girly to mine it um okay this is my account and I have a balance now I want to execute some transaction I could deploy it from here but I wanted to deploy it as part of a transaction so I don't have an application here so I opened the etherscan on some well-known sample application this is The Grater of open Zeppelin and it has a set greeting method so I connect a the trampoline and here it shows it's metamask because this is how etherscan connect to a browser extension I think they're all called okay I I get a connection request for the application so I will connect to it again there is a custom screen that I didn't use in this sample I have a better sample that uses fingerprint but I'm sorry I didn't have to put it on chain this is this screen is this is my bundler this shows the transaction that it sent and ran it locally and in a few seconds it will show that the transaction got mined Central the bundle and now if we look we will be able to see this transaction smooth this is the transaction uh it goes not from my account it's a transaction from the bundler to the entry point and it's in internally it uh it's a transaction that handles a the transaction the user operation of this account oh it starts all over okay they say they don't have much time so if you want if you have more questions you're left to a come over approach me in a okay thank you

Automatic transcript — names and jargon may be misspelled.