EIP-7702: Programmable Accounts and the Future of UX on Ethereum & Rollups

Transcript

[Music] Hi everybody, my name is Martin. I'm from Zirkit. We are a layer 2 that turns every single project on our network into an unhackable project. And I want to be talking about EIP7702 here at Khan. Please welcome. Uh we will dive right into it. So EIP7702 is an EIP that was uh deployed on Athereum within the Pectra upgrade. It was uh authored by Vitalik and some other people and it essentially introduces a new transaction type onto

Ethereum called set code transaction. So let me explain to you what it does. Uh I like to think about it this way. It's a little bit simplified version but it's actually easy to comprehend. So imagine that you or me are executing executing a transaction. It's an absolutely normal Ethereum transaction that you have done any time before. If you want to treat a transaction as a set code, you have the opportunity to collect from other people authorizations and authorize their accounts to execute some logic. So you have the power to set code for their accounts. What is set code? Set code is

an instruction that delegates the logic of the externally owned account to a smart contract. So essentially the externally owned account will then start offering the interface of the smart contract and you will be able to call the methods that that smart contract offers and the deal is that the account will be executing those methods in the context of its own storage. Okay, but it will still be a regular account. So somebody namely you will hold the private key. So if you want to initiate a transaction directly from that account, you can actually do so.

How is it implemented? Well, in Ethereum, we have something called the transaction type. Uh we always had transaction type number one. That's the regular transaction before we broke down the gas fees into priority fees and base fees. Then later uh in the London fork, we introduced uh transaction type number two which breaks the gas pricing into gas fees uh into priority fees and uh base fees and introduces the burn. Then we had transaction type three. That's the blob transaction that submits data. Now we also have transaction type four and that's the set code transaction. So the set code transaction it's actually a serialization of all these transaction values and all of them except for this

authorization list are present in every single at least type two Athereum transaction. So nothing there is new except for this field. What do we record in this field? Well, in this field we record the list of those permissions to record authorization. So this list is a serialization of these tpples and these tpples during the execution of my absolutely regular normal transaction will be first processed before executing the logic of the transa transaction. So each tpple will store the information which essentially indicates that on this chain ID the account represented by this

signature wishes to delegate its logic to this address or to the smart contract that is present at this address. So this is what we sign this is what we give to that somebody that submits the transaction and this will be processed when it's being processed. Then for each tpple uh we essentially write a delegation designator in the storage of the account represented by this signature and the designator is some you know magic constant. It's this fixed uh prefix 0x ef1 uh concatenated with the address and it's this particular address. So this is what we store into the state of

Athereum. And then the deal is whenever you are trying to load an instruction uh from the account that you're you know executing on you actually have to follow this as a pointer. So you have to load the instructions uh from that address. So this is EIP702. Now uh it was actually primarily introduced with the account abstraction intention. It's not the first EIP introducing uh account abstraction to Ethereum. Uh I will be talking about that later in the talk. But this was the primary motivator. My primary motivator for this talk was to actually go through our chain and all the other L2s and tell you about how the adoption of uh EIP7702

in the space looks and what cool projects I'm actually seeing. And I realized that I actually cannot do that. And I cannot do that because we actually live in the world where wallets are very opinionated and they do not allow their users to sign arbitrary delegations. They are actually trying to protect their users because you know those delegations they can delegate the account logic to an arbitrary code. So what if that code allows somebody to drain the content of the account, right? So this is sort of their thinking. And so just to show you graphically the problem happens here uh you have that authorization list that need to submit.

In that authorization list you have to have these serialized things that are signed. So uh the wallets are saying you know please don't do that we will not let you sign that. All right what happened here? So I changed the concept of the talk and uh I will be telling you about what cool stuff you could actually build if the wallets were allowing you to do that. So let me hop into this. So what could we build if wallets uh allow signing authorizations even before uh EIP702 came out uh there were like some use cases that were very very often mentioned at conferences at hackathons and so on. So this is the typical one.

Spend 10% of funds that are in my account. On Ethereum natively in the protocol, you actually do not have any possibility to allow somebody to use Ether that is stored in your account. Right? This is actually one of the basic premises that we have. So with EIP7702, you can implement features such as allowing somebody to spend up to fixed number of ETH from your account, up to fixed number of ETH of your account every day or some percentage of some currency, maybe ETH, maybe another token and it allows you to do that. You could uh use this to implement various features. So you could uh implement regular contributions to some saving

accounts where the you know savings protocols will be just like taking the money regularly. You can you know uh implement various allowances and systems where uh you give uh you know uh AI bots for example the opportunity to start spending ether in your account or various subscriptions. How would you do it? You would do it somehow similarly to this. So you have a smart contract. Uh you would want to delegate your EOA logic to this. That smart contract would essentially contain or need to contain probably two methods. One would be called spend. It would be completely externally callable method. So anybody could come and invoke this method on

your account. What you would do in here? Well, the first thing that you should do is you you should actually check that that somebody who just showed up was actually intended to call this method. So you would spike it with some authorization feature and provided that the you know person or another account is authorized to spend from your account then you would actively actually execute the logic for the spending. So you would snapshot your current balance. You would snapshot the current time. Then you would calculate, you know, how much was spent before by this entity, whether the request for spending more is actually still within the limits. Then you would update your accounting and then you would eventually transfer the uh assets

to them. And all of that would happen automatically at the request of the person who actually submitted the transaction. Well, and then on on top of it, you would need some authorization method that will actually allow you and only you. I have this check in here to express that this is supposed to be only you to record the people that are able to call your generally unconstrained uh spend method. So this is you know the idea how EIP7702 would be or should be used to actually uh develop various applications. So let's start dreaming. What else could you actually develop using this? So, I already talked about the subscriptions and allowances, but you could do cooler

stuff. For example, you could take your EOA and you could delegate the logic to a multisig, right? What would happen or some adjusted implementation of the multisc. I should preface this with saying that uh EIP7702 does have some gotchas. So, like you know the code needs to be prepared for it. But so if you envision uh delegating the logic of your wallet to a multisig suddenly you would uh end up with an account that you know can have escalated privileges but those privileges always have that private key on top where they do not apply. And this would be useful, for example, for those, you know, uh, lovehate relationships with your

accounting department when they actually want to approve your transactions every single time, but you have just spilled coffee on your white shirt and you need to go spend your crypto right now and nobody can give you the approval, so you're just going to do it, right? So, this is delegating to a multisig. What else could we do? Well, how about delegating to some implementation of an automated market maker? Imagine something like, you know, unis swap v2. If you actually took your wallet, put some tokens in there, you know, let's say USDC, USDT. You care that you have a dollar balance and is somewhat stable, but what makes, you know, you couldn't care less. Well, then delegate your account to an AMM hold your wealth in

there and tell the world, hey guys, if you want to swap between USDT and USDC, I have my wallet and it's loaded with those tokens. Go ahead. It now works like unis swap just you know in your personal account. That's actually pretty cool right? In general you could you know future proof your smart contracts or or externally owned accounts. We very often implement smart contracts for the sake of composibility. We kind of want to interact with multiple protocols in the you know blockchain world but not all the protocols were implemented yet.

Right? Imagine year 2042 you will have your favorite lending protocol. it doesn't exist yet. So what you can do with EIP7702 in general, you know, with the operational mindset, you can always undelegate an implementation from your account that happens through overriding with zero address and then you can delegate it to something else. So future proof your EOS in general, I'm actually a huge fan of DeFi. you know uh the 2020 2021 those were the years that I really really loved and uh life was amazing. Uh I like to actually interact with D5 protocols uh through smart contracts and scripts because they allow me to simply execute

you know m multiple complex actions. But whenever I would interact with D5 protocols through a smart contract, I would always had to make sure that my smart contract is implemented in a way that if in the future it receives some sort of exotic assets that I will be able to extract those assets, right, from some future airdrops. Well, now I don't have to do that because I actually can have my smart implementation for DeFi actions. I can actually delegate uh you know my externally owned account to the logic of that contract. I can be using, you know, the D5 protocols in the way how I want to be using them for as long as I want to be using them. And if in the future something lands in my

wallet, I have the certainty that I will be able to work with it because I actually hold the private key to the wallet and I can, right? A very interesting thing that is now possible with EIP702, it's actually possible for protocols. So, you know, imagine your favorite lending platform to define with which wallets or which class of wallets they are willing to interact. This was still not possible unless you actually recorded the full list inside of your smart contract. Now, it actually is. Let me tell you how. Imagine that you are the D5 protocol and you want to let only wallets that have certain specific implementation behind them work

with your externally owned account and the logic behind it or sorry or with your protocol. So you can actually execute get code. You can take a look what is stored in the storage of that uh account, right? And if it is not the special delegation designator followed by the address that you actually want it, right? Then you will revert the transaction otherwise you will keep executing. This is how you can actually create a class of addresses that are allowed to interact with your protocol. And by forcing a very specific implementation for this EIP7702 that needs to be delegated to you can actually protect your protocol because those will be the only actions that you can actually invoke on the protocol. So

this is super interesting. Then you know clearly you can use it for creating or turning your accounts into smart contract proxies that can be very easily upgraded. you have the private key and uh then you are able to execute multiple transactions in one because as I said this was actually created all for the uh you know with the intention of uh somehow bringing account abstraction closer to the protocol of Ethereum natively. So back to that as I said EIP 7702 is actually meant to coexist with EIP 4337. 4337 is the preceding EIP.

It's actually from year uh 2021. Uh some of the authors are the same. So EIP7702 is you know not replacing this. Both of them should exist. So let me sort of tell you how they work, how they compare and I'm going to finish my talk with two appeals. One to the community and one to the wallets. So 4337 the idea here is that you will actually start again using a smart contract as your proxy to interact with the rest of the blockchain. Right? But the idea is that you have your EOA and right at the beginning you will actually have to deploy that smart contract that you will be using as your wallet and then because you want to interact

through here you will take your assets and you will move them to that smart contract. Okay. And then it continues as follows. This smart contract is supposed to contain that you know unrestricted unprotected externally callable function uh with some general execution that is accept that is capable of accepting uh a payload and executing transaction based on that payload. So the way how we do it or how we intend to do it is that we say we have some other service called a bundler and the role of the bundler is to collect these user operations that were authorized to be executed using using this execute method and invoke that execute method uh on your uh smart

contract that you are using as a wallet and that for you will be interacting with the rest of the chain. Here is another picture how it works. So you have those users, users create user operations that somehow on the logical level forms a memp pool bundlers draw for it. Then they call those execute operations that somehow creates a transaction that goes onto Ethereum and eventually the transaction will find itself in some bundle transaction. And as I said, this is from 2021. So a lot of stuff was already developed. We have some wallet implementations. We have some bundler implementations. uh you know they're in all the possible relevant languages. So this actually has a pretty rich ecosystem. The idea with

7702 is that this is sort of similar except for the first step. So here I said you are not deploying your account but you will actually take that implementation and you will delegate that account to that logic. The rest sort of remains the same. Again, you will be signing your user operations and the bundler will be executing them using your account. What disappears from here is the necessity to take all your assets and actually move them over because this first step didn't change the address. So that's it. This is how it looks by side by side. They are meant to coexist.

So two community appeals to finish with. Uh first one is to the wallets. Dear wallets please let us use 7702 to the fullest extent. Do not be opiniated about what account I can delegate to or should delegate to. Don't force us into particular frameworks. There is a lot of beautiful stuff that can be actually developed using this. And if you need convincing, well, I can already do this. There is a button in every wallet to show me my private key. You know, I can take a look at it. And then if you don't give me the chance to actually sign a set code transaction with that key, I will probably copy it into my clipboard and

try to, you know, implement the script and so on. And that's even less safe, right? So give me some expert mode. Make me type some confirmation phrase or hold the button for 5 seconds or whatever before you sign that transaction, but please do give me a chance to sign it. By the way, if you haven't tried scanning my MetaMask private key, you probably actually should. Uh, next appeal builders please. 7702 is here. It's actually uh readily supported pretty much all around the Ethereum ecosystem. Every almost every network supports it, including Zirkit, including some test nets. So, go ahead and try developing something cool with this EIP.

You know, figure out some new project, something that we haven't seen in crypto yet. And there is going to be a hackathon here at ETH Global during the weekend. We have uh $10,000 in prizes from Zirkit. Some of them are revolving around 7702. Again, a QR code for you. With that, I would like to thank you for your attention. Uh we actually do have a booth upstairs. So, if you like to talk to me or, you know, anybody else from the team or pick up some cool swag, please pop by. Otherwise, thank you a lot for the attention and have a beautiful rest of the day.

[Music]