Martin Derka I EIP 7702 on Ethereum and Rollups What to Build and How I Pragma Taipei 2025

[Music] talk about that is going to be Martin from Zade. So, please give Martin a big round of applause. Hi everybody, welcome. Uh my name is Martin. I'm from Zirkit.

Um, can I get the slide deck or Ah, I acted on my slide deck. Okay, so I'm from Zirkit. I am the technical lead and co-founder and these are our cats. Uh, we turn them into plushies. We put them on t-shirts.

We turn them into stickers. And we do it to the extent that some people actually think that we are a t-shirt company or a swag company. This is not true. We actually build a blockchain. uh zirkit is uh ethereum or em equivalent uh zero knowledge rollup and this talk is going to be semi-technical and I will be talking about EIP7702.

So what is EIP7702? Uh let me give you my stab as at a lightweight explanation of what this you know EIP sort of brings and how it operates. So if you want to understand the IP7702, imagine that you are submitting a transaction. It is an absolutely regular ordinary transaction and all of you know how to do that. Okay.

But while you are submitting this transaction, you have some additional privilege. This privilege is to invoke something called set code for your account or accounts that gave you authorization to do so. So now we need to understand what a set code is. Set code is a special instruction that delegates the logic of your externally owned account to some smart contract. Okay.

So your account will essentially become this smart contract. It will start offering the interface to you and anybody else in the internet and they will be able to call those methods and functions on that account. Okay. And the account itself then will be executing those functions in its own context. So there will be upd up updating its own balance.

It will be updating its own storage and so on. But at the same time it will still be an account. So you will have the private key and you can initiate transactions directly from this account. So this is what EIP7702 does. How it is implemented?

Well, it introduces some new transaction. The transaction type for this transaction will be four. Transaction type number one. Those are the regular transactions that we always had on Ethereum. Number two came with the London fork with EIP1559 that separates the gas configuration prior priority fees and base fees.

Then type three transactions those are the blob transactions and type four transaction is a set code transaction. And as I said it is an absolutely regular transaction. So all these black things they are actually already contained in every single transaction that you already submit. The new part that comes with EIP7702 is only this part called authorization list and those are the authorizations to delegate the accounts. So when you take a look at this authorization, it's a list of lists that look like this.

And each of these tupils essentially authorizes us to delegate the account on the given chain to some given smart contract. The nons just specifies the nons of the account and the rest is a signature. So at the beginning of processing that very regular transaction when you know setting code for accounts we go through these tupils and what we do is to the account storage uh sorry to the code storage of each account that was part of this authorization list. We run write some kind of a delegation designator. You can imagine it as a pointer and that consists of some magic constant plus the address that is here and that will tell us what smart contract this particular account points to and then it literally behaves like a pointer.

So if you're executing some code and then code is loading instructions from some account, it has to follow the pointer and load the uh instructions from the uh smart contract that the account is delegated to. And that is all. So what can I build with this? I'm going to follow with short laundry list of various use cases, you know, that uh I heard of or that I was able to come up with just to illustrate how powerful this really is. So if you know something about EVM and about building smart contracts and how Ethereum works, right now you actually do not have any means of allowing somebody else to manipulate with ether in your account.

There is no approval for you know somebody else to be able to withdraw your account uh from your account. With uh EIP7702 we suddenly get the possibility to delegate the account to some smart contract that allows some other people to spend assets from that account. That can be ETH. It can be absolute numbers of ETH. It can be percentages of ETH over some kind of an interval.

So you can very easily start using this to building subscriptions or allowances. For example, you know, let an AI bot to spend 10% of your account every single week or something like that. What you can also do is uh turn your EOA into a multi-IG, but a multisig that also has a private key, right? So the use case for this uh would be the situations when you have the lovehate relationship with your accounting department. You you know typically want them to approve every single spend transaction that you do up until certain point when you have an emergency and you actually need to overspend or literally right now you know you need to buy new shoes uh because yours fell apart.

So that's the moment when you actually pull out your private key and execute the transaction directly and you know the accounting department they can take a look at it later if they want to. But you can go much much much more crazy. So imagine that you load your account with a whole bunch of assets. You put ETH in it, some stable coins, some other tokens. Well, you can imagine that you would delegate your account to some implementation of something like unis swap or essentially some general market pool and turn your own account into an automated like market maker where other people can swap assets between those what uh the assets that you have in your account and you start charging fees, right?

But at the same time, this is still your personal account that you have floated into your wallet, MetaMask or something like that. And you can also think about your account as sort of this like futureproof smart account that you will be always able to integrate with other protocols even if they do not exist yet, right? Because you can always replace your delegation with a delegation to a new updated implementation that integrates with something new. One of my favorite possible use cases here is I would really like to build for myself a smart account that allows me to interact with DeFi and protects me from fat finger errors, right? I want to trade on unis swap and I made a typo and suddenly, you know, the money is gone or something like that.

You will be able to implement templates that protect you from this. And the benefit will be that if you receive any kind of future airdrops or assets, you know, that again do not maybe exist yet or have some special interface or some special way of interacting with them, you will be able to use them. You will be able to extract them from that account because again you have a private key for it, right? There's nothing that you couldn't do with it. So this is actually really cool.

Another cool thing is EIP7702 is here not only for the owners of those externally owned accounts but actually also for protocols. So imagine again that you are building a D5 protocol. What you could do is you can restrict the possibility to interact with your protocol only to the accounts that are delegated to some certain template and you could enforce that this interaction happens through the template. So if you are concerned about uh getting hacked through you know some weird orchestration of transactions you can actually make it go away because you can say hey I will only allow people to execute one deposit one withdrawal or something like that. You can essentially prescribe the ways how your protocols will be interacted with.

You can also think about your uh externally owned accounts as proxies that you can easily upgrade, right? Because you have the smart uh private key, you can always update the delegation. And my really really favorite use case is that you can make your externally old accounts execute multiple transactions in one with a signals single signature and single necessity to sort of wait for the processing on chain which is probably at least to me the most powerful aspect of 7702 and I will spend the rest of the talk talking about that use case. So before I go there, I kind of want to give you an example of how such a template uh for a smart account would look. So I have one in here is that use case that allows some other accounts to spend funds for example ether, right?

So in this particular implementation, you would probably look only for two methods. One would be to authorize the spenders to take assets from your account and use them somehow. You would definitely want this method to be protected now because other people you know through 7702 will be able to uh transact on behalf of your account. This protection this message sender equals address this is no longer sufficient. So you would like to equip it with a little bit more something like transaction origin equals this address.

probably you would want to add some re-entry check and then you know you would be able to update the list of the authorized spenders in the spend method. You would check that the sender is authorized and then you would perform some active accounting. You know how much did this person spend already from your account over some interval uh that you have decided to stipulate. Then you would check whether this request to spend some assets is still within the given bounds and if it is then you would send them the funds and uh there we go. So this would be uh an example how you use this.

It's actually very simple smart contract, right? What you can hear uh see here is probably like 20 lines of code. So not very not very difficult. Cool. So back to building stuff that I actually really really consider cool and that's the uh batching and that's the uh way of essentially bundling multiple transactions into a single one.

But I want to sort of introduce it and motivate it properly. So imagine that use case that I want to really build for myself that uh cool DeFi wallet uh and I want to deposit some tokens into protocols. So what I often hear is that EIP7702 will very very simply allow us to batch transactions. And so for example, this kind of defy typical interaction with an ERC20 token when you first need to approve it for some protocol to use it and then deposit it into a protocol in a separate transaction will go away sort of automatically. And depending what kind of, you know, position you have, this may or may not be true.

Uh I'm going to just say that it's not true in the most most most know most naive way and I'm going to explain that. So the interaction that I described works as follows right you are the user you are here you have some ERC20 tokens and if you want to deposit them into some protocol let's say a first you need to send this green transaction to the ERC20 token uh itself saying hey a is allowed to uh use my assets and then you actually talk to a and say hey take so many and so many tokens and deposit them into yourself and a comes to your C20 and actually completes the task Right. So this is how it works. Now when it you know when we teleport or you know project ourselves into uh 1 month uh from now we will have 7702 on Ethereum and we will be able to do something different something smarter where all of this becomes a single transaction flow. So your account is now here.

you would delegate it to some smart contract does that has a function that specifically deposits into a and then anybody including you would be able to trigger this function within the execution of this function your account would talk to the ERC20 and then it would talk to a and that would get completed signal single signature single waiting for confirmation single waiting for the transaction to be actually processed on chain so let me show you where this sort of like this knife approach breaks apart or falls apart. So imagine that situation where I want my super duper uh smart contract wallet or smart account wallet that can interact with a whole bunch of D5 protocols in some convenient way. So we have a we have compound we have unis swap and maybe others and maybe those that do not exist yet. Right? If you wanted to adopt this approach that I just outlined on the previous slide, you would delegate your externally owned account to some smart contract and you would expect that this smart contract actually is able to accommodate the interface of every single D5 protocol that is you know in your target group.

So you would have a specific method for a specific for compound specific for uh unis swap and everything else. And I'm arguing that this is actually not what we want because the reality is that you know I don't want to build complicated smart contracts. I actually want to have only one single method through which I can achieve uh everything. So this is what I'm going to show you now. We need some universality and we need some batching.

I'm not going to take credit for this. This is actually you know same way how EIP7702 is not my invention. I'm just talking about this. This implementation is also not my invention. I'm just talking about this.

Uh take a look at the authors of the multi call smart contract or the safe wallet. Uh those are the people to give credit to. So if we wanted to create a function for universal execution and for batching uh or not a function but a smart contract template. It would be similar to something like this. You would have structures that define the form of a call.

This is the probably simplest way that you can imagine. You just have, you know, target where this call should go to and you have some call data. That's the content of the transaction. And then you would have a function that accepts a list of these calls. It would perform some authorization.

You would probably want to protect it against re-entry. But then you would start a loop. You would loop through all those calls and then you would use the standard solidity means to execute those calls, potentially check for success and so on. And this way we can actually encode interaction with any kind of protocol that currently exists or will exist in the future. You would not want to stop here.

You would definitely want to add some security because you know once again recall that since this is 7702 all of these transactions will be executed on behalf of your account. And let me tell you letting arbitrary people in the internet execute transactions on behalf of your account is a really bad idea. For example, you know what they could do? They could say, "Hey, dear account, talk to the USDC smart contract and transfer all USDC from this account into my account, right?" And you probably do not want to arbitrarily allow everybody to do that.

So, you would want those call batches into that aggregate function that I showed on the previous slide to be signed so that there's some uh ex explicit uh consent of the owner of the account. You would want to implement some anti-re replayability measures. So you know do not forget the chain ID and so on. You would want to implement some kind of nons system so that you can guarantee the order of executions of those uh call batches and you would probably want to implement some invalidation nons so that you can say hey I no longer want to execute anything that I have signed before and this becomes really strong and powerful because it allows us to build something else. It allows us to build relaying services that essentially receive these batches of calls and will be executing them on chain on behalf of users.

This way we can abstract away all the complexity that exists on blockchain. So users may no longer think about you know need to think about the uh gas configurations. The relayer will do it for them. users will no longer need to think about having prefunded accounts with assets to cover gas. The relayer can be covering that for them, right?

The front ends will no longer need to wait for slow transactions. So all those debates whether we have like 200 millisecond block time or you know 1 second block time or 3 secondond block time this will go away because again we are moving back to the web two space where everything is a communication between the client and a server in the traditional web two way that we have been using for the past you know two or three decades and for which we actually know how to build good uh user experience and good interfaces for. So before I move on to the last part of my talk, uh EIP7702 is a new standard and it actually calls for more standards. Right? I'm talking about some templates that we will be inviting people to delegate the functionality of their accounts to.

You would really really want this to be standardized. So if you want to work on some standards for EIP7702 and the templates, hit me up. I'm down. Cool. So why do I feel that you know I can talk to you about EIP7702 because as I said this is not my uh EIP it's written by Vitalic and other people.

It is because we spend a great time at Zirkit building around EIP7702. So spoiler alert at the end of April together with Pekra on Athereum we are going to enable the EIP7702 functionality on Zirkit and it will be done properly in the zirkuit way so that all the transactions that are you know delegating accounts functionalities or transacting on behalf of those accounts are properly scanned uh by our special feature that we call sequencer level security. So in practice it will look like this. You will have some EOA. We will provide you with a template.

It will be very similar to the template for that universal execution and batching that I have showed you before. And that will be able to interact with all the protocols that are currently deployed on circuit. On top of that, we've built this beautiful relayer which I already described to you as well. It will essentially be a restful API commonly known from web 2 that will expose two important methods. One will allow you to set code and the other one will allow for executing uh methods on chain.

You will not need to worry about gas. You know we run the sequencer. We collect the gas fees. We can fund this relayer sort of infinitely. And we are doing it so that you and other builders in the community can build this cool front ends mobile applications who are switching between a wallet and your you know app is really really clumsy so that if you have a settlement server that really needs to transact very often or trading bots so that you can do it through this relayer or you know if you're into AI agents and want to give them a little bit more power for transacting you can do that as well.

With that, I would like to thank you for my attention, for your attention. If you have any questions, catch me after the conference. I'll be around. Thank you. [Music]