EIP-7702: Set Code for EOAs

Transcript

7702 allows your UA account to now have code by pointing to other code. What is 7702? It's basically what we're going to do is we're going to introduce a way that you can upgrade your UA. And you can upgrade your wallet to have all the same capabilities as a smart contract wallet. The biggest drawback of 7702 is Welcome to PEEPanEIP, the podcast where

we dive deep into improvement proposals and protocol shaping Ethereum ecosystem. This is episode 148 brought to you by ECH Institute, and I'm your host Pooja Ranjan. Today we are exploring one of the most talked about proposals in Petra upgrade, EIP 7702 set code for EUAs. What is EIP 7702 and why is it a big deal for mainstream Ethereum users?

To help us break it all down, I'm thrilled to be joined by Anders Christian Sen, senior client developer at Nethermind. Welcome, Anders. Thank you for having me. I really appreciate you taking out time from busy week. I understand Petra mainnet upgrade has been announced. It is on May 7th, so it's almost there. And I'm excited to learn about EIP 7702, which is considered to be one of the most important EIP of this upgrade. Well, we will unpack how this proposal works, what it is for developers and for users. But before we get into tech part, how about let's know a little bit about yourself. Anders, will you please share about your professional background and how you joined Ethereum?

Sure. Uh so, I have a background in the computer science and then in pretty early on I learned about Bitcoin and thought that was pretty interesting, but this was back in all the way in 2012 and just buying Bitcoin back then was a extremely difficult. I mean, the hoops you had to jump through. So, I didn't really even though I thought it was intellectually interesting, I didn't really participate much in it. And it wasn't really until I heard about Ethereum that it got me more interested.

So, in um around 2016, I started doing a bit of uh uh smart contracts and that kind of thing and got more and more involved in the um the blockchain space. Decided that I should try going independent, so I started like a consultancy and ended up in 2023 joining Nethermind working on the core client, which I think is quite exciting and interesting.

Yeah, I'm I find it pretty uh enjoyable to be like at the forefront of blockchain engineering and innovation. It's pretty cool to be a client dev, so I can understand the excitement behind it. Thank you so much for sharing that. So, with introduction out of the way, I believe there is a presentation that we have here for today. So, without further ado, let's peep in. Sure. Yeah, so we are here to talk about 7702. Like you mentioned, it's probably the most interesting upgrade coming up in Petra because basically we are trying to bring early version of account abstraction to Ethereum. So, what is 7702? It's basically what we're going to do is um

we're going to introduce a way that you can upgrade your EOA, which is your for those who don't know, it's what you use in your wallet, the the thing that you sign transaction with, that's an EOA. Contrary to a smart contract, which doesn't have any signing rights. But with 7702, now you can basically upgrade your EOA account to a smart contract, which it gives you some really nice benefits. So, and the big thing that that makes this kind of special is that we've always had multi-sig and uh no safe and that kind of thing. So, advanced wallets, smart

contract wallets. But with 7702, you can turn the EOA that you have probably used since forever collecting all your meme coins and NFTs, uh whatever else, and you can upgrade your uh wallet to have all the same capabilities as a smart contract wallet. So, in a way this is like bridging the gap in between what we have today, which is sort of this like dumb version of a wallet which which doesn't do anything but just sign transactions basically.

Uh that's all it can do. To being able to have all the features and benefits of a smart contract wallet. So, what did we do with this? So, basically, yeah, we're going to talk talk about motivation. So, I I was already alluding to it. Why is it good to have a smart contract wallet? So, it gives you a a lot of possibilities that was not possible before. Uh for example, you can do batching. So, now we can start batching transaction into much smaller components. So, you can imagine that you have a centralized batcher,

and maybe even a like a web3 wallet provider who could be MetaMask who batches up all the transactions within the last 1 second or whatever. So, you can have maybe even up to hundreds of transactions all batched together. And because they're batched together, then you can save some gas. You can also have uh sponsored transactions, which is probably one of the like the major benefits of doing this. So, I think most people have run into the problem of having a a new account uh which is unfunded, having no ETH, so there's zero ETH.

And now you even though you have the account, you can't do anything with it. So, so maybe someone sent you some meme coins or maybe someone sent you some stablecoins. But, there's nothing you can do with it. And that's very typical when uh you do bridging or someone does a withdrawal from an um centralized exchange that they uh move it to they choose some network which because they had the cheapest fees. But, uh what they didn't realize is that uh on that network their account uh is not funded. And then what do you do?

That's pretty annoying. So, then you have to go to back to the exchange and buy some ETH and then withdraw it to the same network and and make sure you you select the same network. And to many users, this is very confusing and not a very nice user experience. And it even allows wallet providers to basically abstract the way the chain since um you can even introduce other sort of signing credentials into your EOA now if it becomes a delegated account, as we call it in 7702. So, it basically means that instead of using the standard signing methods that we use on on Ethereum, you could choose anything. You could choose, for example, having a

just like in Bitcoin, or you could even choose something that's quantum-resistant, or maybe even some sort of um funny like a web two single sign-on. Whatever it is, there's no real limit to what you could potentially do. And because you can abstract the signing credentials away, that actually allow a wallet provider to also provide a sort of chain abstraction experience. So, in a sense, you no longer have to care about which chain you're on, and you no longer have to choose which network now you're currently on.

You could just have your wallet. So, I think that's one of the probably the key benefits of doing this, of course, it requires a lot of work from wallet providers, and there's going to be quite some time where people will experiment and try to figure out what is the best design here and and uh deliver the best possible user experience. But I think in the end, it's going to be quite a bit better than what we are traditionally used to, which and I think most people can agree that the current user experience on Ethereum is not the great when the basically have the base layer, and we have uh all these roll-ups, basically like small little islands, which for a user is

quite difficult to navigate. But if you had something like account abstraction and chain abstraction, then suddenly you can deliver a much more nicer user experience. So, how it works from a technical point of view, we've introduced this uh new transaction type four, and basically this type of transaction just carries some extra data, or rather it's a list of extra data that designates your account, what your account should point to, and also something called a nonce for security reasons, and then also your signature. So, if you want to have experience the benefit of 712, what you will need to do is you will need to sign a request, which most

likely will be in your wallet. So, at some point MetaMask is probably going to include this feature, and you could potentially upgrade your MetaMask account to a delegated account. And to do so, you would need to sign, and then we can imagine that most likely MetaMask would want to collect a lot of requests because actually there's no limit, other than gas, to how many requests you can have in a single type four transaction. So, this could be done by a centralized provider, we would imagine, uh because that's the most efficient way of doing it. So, we can imagine someone like MetaMask, or

another big wallet provider, collecting all these signatures, and then sending off the transaction. And when this transaction has been verified on chain, all your accounts will then have been upgraded. So, what happens is basically on Ethereum, all accounts uh have a couple of things. They have a nonce, they have a a balance, and they have a code. And up until now, an EUA could never have code. There's no way, technically speaking, that a an EUA could have code, and that's quite a deliberate decision up until this point. So, basically 712

allows your EUA account to now have code by pointing to other code. And that's a a pretty important distinction. So, a normal smart contract, when you deploy it, you will create an account. It will have a balance. It will have a nonce. And it will also include the code that you provided in the transaction that you used to create the smart contract. In a 7702 transaction, you do not provide the code itself. You just point to the code.

So, we can imagine that there's going to be some Of course, there's going to be a period of iteration where people or experimentation where people will figure out, "Okay, what's the best wallet design here?" so on. But someone will come up with some pretty good designs. And people is generally going to want to use it. Uh imitate it. And so, in when you do your 7702 transaction, you say, "I want to use that smart contract, and I just point to it by saying I want to use that contract code specifically." So, you don't actually send the code itself. You just send the pointer saying,

"My account point to that account and use that code." And to be even more technical, when the EVM transactions run, and your transactions load, when you point to an account, which you have to in a transaction, or if you don't, then it's a then it's a contract creation, which is kind of implicit by not pointing to anything. Then it must be a contract creation. But if you point to something, you point to some address. And in many cases, probably an EUA, where there's zero code. But it could also be a smart contract, like a Uniswap or Compound, or maybe some mean token,

or whatever. And when you point your transaction to an account, what will happen is that it will load up the code, load the code in to the EVM, and then start executing. But in the case of uh delegated account, which you would have when you have 7702 uh delegations, it has uh this uh special designator in the beginning, which says basically that this is not a smart contract. And you are not allowed to run it as a normal smart contract, because you have I have a special designator. But this is indeed a uh pointer.

So I'm pointing somewhere else, and you are not allowed to run me as a code. So, maybe that went over the head of uh majority of people, but basically um that's how it works. And then uh another key thing is that contrary to like as a normal smart contract wallet, which would be just any standard smart contract, uh it's just that it's specifically made for being a wallet, a delegated account still retains the ability to send transactions and sign transactions.

So, a smart contract can by definition not sign a transaction. And actually there's a mechanism inside Ethereum that makes sure that if you are a smart contract, and even though it's by, you know, mathematically impossible that you should have actually a private key attached to that account, you still cannot assign transactions and use them. But on the other side, a 7702 delegated account can still sign transactions and act perfectly the same way as a smart contract wallet. So, it's sort of a um middle ground, where we retain the UAs, what we know and have used for so many years, and still gaining the

ability of being a smart contract wallet with all those benefits. Now, you could say, "So, one problem with that, because you retain the ability to keep signing transactions, is that at some point we will have to upgrade the signature scheme we are currently using. It's called the ECDSA with some elliptic curve magic math. The problem with the scheme is that uh it's it's not quantum resistant, and at some point it will be simply outdated. And same thing on Bitcoin, actually. So, at some point we will have to update and uh upgrade this

signature scheme. However, we are many, many years away from this, so it's it's not a threat at all at the moment. But, by updating your EOA to a smart contract wallet, like I said earlier, you gain the ability to basically use any signature scheme that you could think of. It could literally be anything because it just you can just program it. So, it could be as secret as as knowing a secret to a phrase, which would be a very, very dumb design, but could also be something that's quantum resistant.

Yeah, basically anything that you could think of. And I made some just a quick graph I made just for anyone who didn't follow. So, before we have an EOA, it doesn't do anything but sign transactions. That's all it can do. And then it can hold the balance and have a nonce, and that's basically it. With 7702, we can point to basically any smart contract, and then suddenly gain the ability and functionality of whatever we're pointing to. So, it could be a an advanced wallet. It could even be stupid meme token if you wanted your EUA to be a meme token, you could

theoretically do that. All right. So, challenges. So, of course, there's naturally some challenges because this is really something that has never been done before on Ethereum. So, basically, we're taking EUAs, which we are used to having certain invariants, certain things that we used to take for granted because an EUA cannot have code, but now suddenly they can. So, as an example, in the EVM, we have like these variables that tells you something about how the transaction or the current environment of the transaction, like where it came from,

who's currently executing, how much gas you have, and that kind of thing. And one of these things is what we call the origin, which is the original signer. So, it's always an EUA because only an EUA is able to sign transactions that that can be executed, and nothing else can. And because of this, some dApps, some applications have used this knowledge to check if I am currently executing at like the top-most layer.

And so, in the EVM, it's kind of like a stack. I mean, if you know computer science, maybe you're familiar. But inside the EVM, you can do a call, which would create another stack, and then inside that stack, you could potentially call again, and again, and again, and you build up the whole stack. And this is actually very, very common in DeFi. That's one of the things that makes DeFi so powerful because we have all these building blocks where one protocol is able to call into another protocol and you can do flash loans and all sorts of things. And back in the day, some people used to use this

assumption that the origin is an EOA and if my current call stack it's also so my the originator of my call stack is also an EOA or is um it's the same as the originator, then I must be on the first stack. And some protocols use this for guarding itself against things like reentrancy. So, that's like the number one vulnerability in all of DeFi. And basically, it's a bad way of doing it and easier and better ways to check if you have a reentrancy in your logic. So, we did consider that this would break this assumption, but in the end we

didn't really think it was that important because most secure protocols do not do this and it's basically only like old code that yeah, it's bad practice essentially to do it like this. Then maybe more interestingly, in the mempool, we also have some assumptions because if an EOA is only able to sign transactions and only those transactions can be executed, then only EOA transactions can affect the EOA account of the same.

So, in the mempool, we do a lot of things to try to prevent those attacks. So, when you're running a client in your server mempool, and the mempool for you people who don't know, that's the pool of memory where all the current known transactions are. So, whenever you send off a transaction to an RPC, it will end up in the mempool. Then the builders is going to pick it up and then include it. And now there's a caveat because nowadays actually most transactions is what we call dark pool.

Which means that there's actually transactions that was never in the mempool because nowadays we have all this MEV and specialized block builders who outside the public available mempool build blocks. But anyways, or because the mempool is public and because anyone can send transactions, we need to have some sort of mechanism to make sure that we're not get just getting spammed. Because anyone running a node has a certain amount of memory and if anyone can just create transactions and send transactions to your node, then at some point you're going to run out of memory, quite simply. So,

usually we have some rules. When we receive a transaction, we check that the nonce is correct, that you actually have funds in the account to pay for it. Otherwise, we just reject it. Because there's no point in accepting a transaction which has basically zero chance of actually being included. And this 7702 actually flips up and down some of those assumptions that we have. Because if your EUA is now able to run code, it also means that your EUA is able to transfer ETH, transfer stablecoins,

transfer NFTs, or whatever else without the EUA ever signing anything. And that makes sense because otherwise, how could it be possible for you to send transactions without ever spending ETH. So, the problem then is that because those we have an assumption that only an EOA signed transaction can swipe your account, for example. So, only an EOA could potentially take all the ETH out of the account.

So, only an EOA signed transaction could remove your balance. That was the assumption before. Now, with 712, that assumption is out the window. So, basically we had to come up with some new rules, and it gets a little bit complicated because the memory pool is kind of a like a sensitive thing in terms of performance. It needs to be quite performant. For me, it actually took a little bit of a back and forth. Basically, what we figured out was very very simple. If you are a delegated account now, we will only accept your transaction if the nonce you used for that account matches the current one. So, the nonce, which is uh I mentioned before,

the nonce is something that exists in your account that gets incremented every time you make a transaction. The reason being that we do not want your transaction to be replayed by anyone, meaning that if this nonce did not exist, then potentially what could happen is that because the mempool is public and all the blocks are public, anyone in the world can just take your transaction and then just send it again. And there's no way because there was no nonce, there's no way of like distinguishing did he actually sign a new transaction or or some some guy who's playing tricks.

So, the nonce is very very important, basically to prevent this. And in the mempool, we simply just say include your transaction in the mempool, the nonce you used has to match the current state. And uh in that way you cannot spam mempool any longer and the amount of transactions, so the what we're basically trying to prevent in the mempool like if you run this scenario you have a delegated account and you can create lots of delegated accounts and if we if there was just do it did it as as before then you could potentially create just thousands and thousands of transactions

and just spam the mempool and then you just set low gas prices, so these are but not too low, so it will still be accepted into the mempool and then just before the the transactions would execute then someone sent the transaction with a high gas priority that gets prioritized to the others and that because all the accounts are delegated and running smart contract wallet logic, it sweeps all of their balances and basically invalidates all those transactions that you tried to to send before.

So it's like a very cheap way of trying to dust the network and that's basically what we're trying to prevent. So yeah, that was a long-winded story, but that was basically that was probably the the hardest challenge which turned out actually to be very very easy. I just had have to think a little bit and then it's pretty straightforward. Yeah, and then um maybe I should also mention that this is not a like full replacement for account abstraction like I I talked about a little bit about it before. So this is not like the end game for account abstraction. One of the drawbacks like I mentioned before that we're still depending on this ECDSA

signature scheme which will not last forever and it's it's going to be duplicated at at some point. And the weakness here is that if you delegated your account and you retain the EOA signature ability then at some point when quantum computers become a reality, your account will be exposed and vulnerable. So, some people speculated that okay, we at some point maybe we will include an upgrade where first you delegate your account and then you can also upgrade your account by throwing away the keys like sending a new transaction that says "Hey, I have a delegated account now. Throw away my keys.

Never ever accept an EOA assigned assigned transaction from this account again." And then you you would sort of have full smart contract ability and no longer be dependent on any old-style signature. All right. So, some success stories. So, we have pretty strong developer and community support for this. I think many many people have been requesting account abstraction features for a long long time. And to be honest, we could have done this way before. And I'm not really sure. I guess we just maybe we tend to focus a bit too much on like

protocol-level stuff that not so much in things that actually have an impact on users. Which yeah, it's a it's a shame, but I think um we are becoming better at it. We need to listen more to uh users and all the stakeholders in our in our ecosystem. So, yeah, we already had some good feedback from the one of some of the big wallet providers. They're quite excited about this. They see a lot of um potential in it, which was the whole idea.

And yeah, we also saw some demos at ETHDenver of this the potential of this. So, things been quite good so far. Yeah, and that was basically it. So, question time. Thank you so much for this great presentation, Andra. Some I believe this is like ELI5 kind of Generally speaking, when we talk about accounts and smart contracts, it could be very nerdy for people who do not understand smart contract very well. However, this proposal is actually trying to bridge the gap between EOA and the smart contract wallet. So, the way you have explained, I'm sure it will be way easier for anyone learning it or hearing it for the first time to understand what 7702 is. So,

thank you again for that. Yeah, it's it's always a bit of challenge to weigh like technicality and ease of understanding and finding the right balance, you know. No, you made the right balance over there. Very well, with this EIP, I have a few follow-up questions. Starting for the very first one, as you also mentioned that perhaps account abstraction should have been sooner rather than later. And in the time period, we have seen multiple account abstraction proposal EIP-3074, EIP-2938, 4337 was also a variant of that. So,

what is that 7702 brings differently that we are ready for it? Is it just about the timing or is it about the combination of features that we are bringing in? Yeah, I think it's a combination of generally and core and all core. So, in Ethereum, we have all these different client teams and we sit together and when we talk about these different EIPs and the future and the road map and what we should do, and then there's a lot of back and forth, and it's very, very technical, and it's extremely difficult actually to follow all everything that happens. It's basically impossible. But, I feel like what often happens in in all core is that we kind of lose focus on the overall ecosystem,

and then kind of get lost in technicalities, and like more nerdy stuff, and maybe some ideological what do you call that fervor or like uh you tend to talk a lot about things which in theory is very important, but maybe there are more important things to solve right now. I think most people can all users can probably agree that the user experience we have right now is definitely not the best, and there's a lot that can be improved.

But, even though everyone knows this, it doesn't really seem like there's that much focus on it, and and sometimes when some we have focus on uh we should do and we should push, and then other things come in, and then we start talking about other things, and we sort of kind of get lost in the weeds. And yeah, you mentioned there was uh 3074, which is kind of the same or basically tried to achieve the exact same thing as 7702. The problem with it is that it was going to introduce these new we call EVM opcodes, which is sort of similar to CPU instructions, and we didn't really like that because you

cannot remove an EVM opcode at a later point because we have to be backwards compatible. So, anything that ever been deployed on Ethereum, we have always guaranteed it will continue to work as is. And by creating these new opcodes, and at the same time, we are saying that this is just an intermediate step. Like this is not the end game for account abstraction. This is just like a intermediate step where we can actually bring great benefits to users and we don't have to spend huge amount of time of developing something new. This is was like reasonably simple actually to implement. I mean in EIP terms it wasn't such a big thing. And yeah, that was

basically the reason why that got rejected. And then yeah, I mean the story is basically like we had our usual all core dev meeting where we're going to discussing 3074. And then Vitalik shows up and throws a bombshell as he usually does and then says uh "Hey guys, why don't we just do it like this?" Basically what he suggested was uh something very very close to the current form of 7702. The only difference is that in his original proposal the delegations would be ephemeral, meaning that they would only count for the current transaction.

But thinking about it, we thought that no, actually it would be actually better for users if you could have like a more permanent thing that you could upgrade your account with and not have so much It would leave like a a burden for uh an extra burden for wallet providers if they wanted to utilize this. And basically it would be better just to have something that was permanent and which afterwards would interface very well with all the current infrastructure that we have today.

Yeah, that is a very well explained. I understand, but I mean again, it's another topic for debate like having an ephemeral could have been more secured because it's like one-time delegation only and having Yeah. A permanent feature could be difficult, but I don't want to get in there. Let's move on to the next question. So here we are using EIP-2718 for transaction type four. This EIP was deployed with Berlin upgrade. So, what we are doing right now is a use case of that or are we actually modifying 2718? Yeah, 7702 is basically just a new typed transaction just like in Cancun we introduced the blob

transactions and the whole idea behind that EIP is to establish like a standard framework because we know that we were going to introduce new transactions and 702 is definitely not going to be the last transaction type we introduce. We're going to have more to come. Yeah, it's it's basically just follows the the standard typed transaction framework or standard. Right. So, whatever was suggested with the Berlin upgrade, we are just trying to make use of that and come up with it. Very well. My last question with respect to this proposal is if there are anything that a developer should keep in mind, what that would be in terms of security

consideration when a developer is trying to use this proposal in their respective projects. Any best practices or risk you would want Yeah, great question. So, one of the the key things as relating to 7702 and and wallets is that right now we have seen a lot of like these approve requests. So, most Ethereum users are probably aware if you want to interact with an ERC-20 token and you would like to participate in or you would like to swap something on Uniswap, you need to approve the protocol or the dapp to actually spend that token for you and

swap it. The problem with approvals is that bad guys also likes to do approvals and many malicious steps or apps, websites, phishing attacks, you name it. They love to do that. And they love to approve to spend, you know, a million of your USD or shitcoins or whatever it is. But it's sort of limited because if you unintentionally approve some malicious actor to spend a thousand of your USD, well, okay, then you lost a thousand USD.

But if attacker is successful in getting a user to sign a delegation upgrade for the account. So, uh, 721 delegation, the hacker can basically swipe the whole account of absolutely everything. So, there is also a challenge for wallet providers and service providers to educate users now, I think. At this stage we have taught most users that they should not just sign anything that pops up on the screen. Of course, it's impossible to be like 100%. There's always going to be someone who signs something they shouldn't sign. But, yeah, that's probably the biggest

drawback of 721 is that now it also becomes possible for attackers to actually uh, not just sweep your favorite meme coin, but they can sweep your whole account. So, take all your ETH, all your coins, all your NFTs, everything. So, from a security standpoint, it's not great that we have this. But of course you have to outweigh the benefits with the potential security implications. So, wallet providers going to have a big job in education and also making sure that, well, I mean, don't sign anything that you don't know what it is. So, yeah.

Yeah, education in general is very much recommended, but we always have new people joining in. So, there are some possible Yes, like I said, that's it's unfortunate. This will definitely be exploited. That's, you know, the way of the world. So, and the only way really way to combat that is for through education and really I mean, to the merit of many wallet providers, I think the amount of now warnings and pop-ups and uh things that come up whenever you do stuff with your MetaMask or your Trezor or your Ledger, whatever you use, is uh there's way more nowadays than it used to be. They used to be like click, click, and boom, tokens gone.

Now, there's actually some, "Hey, are you sure that you want to do that? Are you sure it's a good idea?" Unfortunately, you could say that uh because the delegation requests are in a specific format, it's easy for a wallet to recognize, "Hey, this is a delegation request. Are you absolutely sure? You need to know exactly what you're doing now. If you sign this, you could potentially lose everything." And so on. So, there's hope that most people will not just sign and click yes, yes, yes.

But, I I don't think we can save everyone, unfortunately. Right. And you also very rightly mentioned that this is not the end of account abstraction, it's just the beginning. So, we hope that there would be some proposal in future which can make it even more foolproof. So, Yes. That is the idea. Yeah, very good. Well, with that, we are done with uh the proposal related, and we are entering into a very interesting round called rapid-fire round. So, we generally try to do this round within 1 minute, or we try to keep answer brief, either one word, one sentence, or briefly if you can respond to that. So, are you ready for it?

Yeah, yeah. All right. What is the first word that comes to mind when you hear EOA with code? Better user experience or user experience. Favorite feature unlocked by EIP-7702. I think that's the the gas paymaster and also the potential in for for chain abstraction that this gives wallets. Yeah, so that's what is most exciting to me. Very well. The next one is most underrated challenge in client development. Following up on everything going up in all core devs.

That's a good one. One EIP you wish people would talk more about. Recently Dankrad proposed increasing the gas limit by 100x in 4 years. I don't remember the number, but I'm pretty sure if you look it up Dankrad 100x gas limit probably comes up. Yeah, and the EIP number is 7938 exponential gas limit increase right you want to follow. Very well. The next question here is would you rather debug a consensus bug or explain gas to your parents?

Oh, wow. Consensus bug. That's generally Yeah, see that's easier. Okay. About L2s, is it inevitable future or necessary evil? No, it's inevitable. Right. One client feature you secretly want to build. Something that does not exist today. I think we should do a lot more in terms of supporting rollups and layer twos. So there's concept of of native rollups and there's also base rollups and there are the potential lots of things that we could do at the protocol level to expedite or help

layer twos especially in terms of interoperability which is one of like the main major pain points for users right now. That it's so difficult navigating all these chains. And also the liquidity and the fragmentation that we have in the current ecosystem. You can move your tokens around reasonably fast, but it's not really that great user experience having to go to a web page to transfer tokens and then to another web page to actually do the thing that you originally wanted to do. And also it's adds cost, of course.

And then the latency. So yeah, I would one feature would be having better support for rollups. I really hope with the new and improved ACD process, we should have room for all other features that we would want to see on Ethereum. Hopefully, hopefully, yeah. Let's see if we can actually coordinate. Sure. Next one is which EL client node do you run at home other than Nethermind if any? Geth. One word to describe Nethermind's dev culture.

Not afraid to break things. Awesome. Well, last question here. One Ethereum upgrade you're personally most excited about next. I guess one of the big ones is fossil but to be honest doesn't really make me super excited. Like there's also the uh Justin Drake's uh beam chain. It's very very interesting concept. Really like it. And generally I would think we should really try to focus more on At the end it's users who uses Ethereum and without them it's pointless.

And we're going to we should provide the best possible experience. Of course without compromising the the core values. But there's lots and lots of ways that we can we can go in that direction without compromising ourselves. So like pointing out a specific feature is difficult but I am I'm excited about native rollups. Yeah, that's pretty interesting and it's upcoming. So, we will have some more conversation around native rollups in upcoming episodes.

Well, thank you. This is time to wrap up. I want to wish you best for Petra upgrade and I understand there is also another watch party. So, I hope you all have a lot of fun there. Yes, going to be a stream, yes. I should have included the link, of course, but yeah, that's going to be a stream on Thursday. No worries. We will try to get the stream link added when we are releasing the video for people to watch. All right, cool. Nice. Very well. A huge thank you to Anders for sharing his insight on EIP-7702 and incredible work which is happening behind the scene at Ethereum clients.

If you're interested in this episode, don't forget to like and subscribe and share it with your fellow Ethereum nerds. For more updates on protocol development, EIPs, and upgrade timelines, follow us at EatTheCatHerders and stay tuned for future episodes of Deep and EIP. Until next time, keep learning, keep building, and stay decentralized. Cheers.