Future of Account Abstraction | Ethereum Korea One: Genesis

Transcript

Hi, I'm Harry, an engineer at Sunnyside Labs. And we are now joined to discuss about the future of account abstraction. So I personally have worked on and followed up on account abstraction on Ethereum for years. and it's an honor to moderate this panel talk about the future of account abstraction in conjunction with these key opinion leaders of the ecosystem.

So let's start with a short intro of each panelist. Felix, could you go first? First? Yeah, so yeah, I'm the current team leader of Geth, and I worked on account abstraction on and off for about three years, I would say, and most recently I was involved in the initial phase of the frame transaction project, but this has been continued by my colleague Matt Garnett, and he is the main person from our side, but I am still very involved in the discussions. Thanks.

Taek, could you introduce yourself briefly? My name is Taek Lee. I work for ZeroDev, and ZeroDev is now Offchain. I do some contracts for smart contract accounts and do the tech lead stuff for whole internal system. And I have been discussing and I have been representing options for both ZeroDev and the Nitro side in the ongoing discussion on the frame transaction and recently.

Thanks for the intros. So we'll start with a brief question about why native account abstraction right now? We have ERC-4337, it's been live for over 3 years, and we have EIP-7702 for over a year. I want to ask why native account abstraction is back on the table in 2026? So I want to hear the perspective of the L1 team.

So Felix, what made the L1 core teams consider that we are ready for native account abstraction? Yeah, I can try to answer this somewhat comprehensively. So with previous solutions such as ERC-4337, they were in some ways a testbed for what account abstraction can achieve, so it was good to test for some limitations of smart accounts and so on, but it does come with a fundamental problem that at the end of the day there is still a key linked to the account, and on the protocol level transactions can only be originated

from a key, and so the idea with native account abstraction is removing that requirement, making it actually possible for users to send transactions directly from the contract, and there were some designs such as EIP-7701 that would basically bring the exact environment from ERC-4337 to mainnet, but as we evaluated that design carefully, we realized that it is not really in the spirit of Ethereum, because it was somewhat prescriptive of the transaction flow, so it was basically a very purpose-built

solution for a very specific transaction flow, and we felt that with frame transactions we have the opportunity to introduce a more general mechanism that also enables all the use cases that were there before, and this idea to make it more general was kind of Vitalik's push, but then he's still part of the push now for frame transactions, but it's mostly, as usual, Vitalik came with the initial idea, but then we started working on the details and he removed himself a bit from that part, so now, just, it's more like in the background now.

Okay, nice, thanks for the answer. So it's like offloading the key out of the protocol so that general use cases like post- quantum support and so on can be enabled on Ethereum. Yes. Yeah. Oh, I want to ask the same question to Taek, like, you've been working closely with L2 teams, right? What is your take on the timing?

I think there is a core difference in this specific native AA discussion on what comes first between L1 and L2. Usually L2s, I cannot represent all the L2s because they have their own opinions, but from my understanding, and through some talks with them, one major issue from their teams is they wanted to separate the PQ migration from the So they wanted some simplified solution without breaking what they are doing right now.

And because like, I mean, it has been quite obvious that quantum migration is quite needed at this point. And like, if we have to do it, I mean, we cannot actually delay it anymore. So that was one of the reasons why the L2s are considered the gateway. And also another major reason is usually, I mean, L2s are more focused on the user experience than like what L2 is. I'm not saying that L1 does not take care of user experience, but there tends to be more interest in user experience than what L1 is prioritizing.

For example, it looks just like this privacy and key isolation and key separation kind of stuff. It is needed, but it has less valuation on the L2. So usually it is more about user experience and PQ migration at this point. Thanks for that valuable opinion, Taek. So yeah, I think both L1 and L2 is pretty much, like, need native account abstraction for different reasons.

Let me dive deeper into this point. I have a question for Taek. You've shipped ERC-4337 and EIP-7702 to real users. Other than the PQ migration, where do they still feel we need account abstraction? So I think it is a sort of problem that has not been solved, but major users have not actually migrated off from their EOAs.

I actually want to check if anyone actually used them or took their own. There are whole assets in there. But yeah, so like, we did ship embedded accounts and session keys and all the use cases that have been enabled, I mean, that has improved user experience in a way, but it is actually far from being actually the first-class type of transaction or first-class account type. So what we actually want to see, I mean, if that was not possible for C7702, is exactly that.

Migrating the users from the EOAs and letting them use at least batching. Thanks for the answer. And Felix, how do you think about this? So do you have any take on what Taek said before? So, making smart accounts a first- class citizen, is that unlocked directly by adopting frame transactions, or do we have anything to do, or more work to do on this?

Yeah, so, how should I say? So for the L1, we want to enable a general primitive that allows users to deploy smart accounts natively. But it's just that I think in the L1, we are a lot more choosy about what this means. We really want to get it right, because we don't have that many chances to introduce something. In some ways you can see that, for example, EIP-7702, this mechanism allows users to convert their account into a smart account by deploying code into an existing address

that is controlled by a key. But again, it doesn't allow you to unlink the key from the account. So even if you turn your account into a smart account, you can still use your key to send ETH from the account even though it's a smart account. So it's not like a real smart account. And so the way we think about it is that the protocol has to enable the fundamental feature, and then the users can use this as a platform to build whatever they want, and we are less concerned about prescribing specific solutions to the user, so we don't actually want to tell the users "this is how you do smart accounts."

It's just, people can figure this out on their own, and there's companies that focus on this. Whatever primitive will be provided by the protocol will be utilized in the end by the smart account implementers, I guess, but we do want to get it right so that it enables all kinds of use cases, and for us specifically, also as part of the as part of our research into native account abstraction, we kind of figured out that there are some other things that we want to enable at the same time. For example, stuff such as transaction assertions, and this is something, and batching.

So this is something that came pretty much initially, also when ZeroDev was very involved from the start in the discussions around frame transactions, and pretty much immediately came and said, yeah, can we just do native batching as well, because this is like a real thing. People really need this. We were like, yeah, okay, we can extend the proposal a little bit so they can have native batching. And then later some other people came from the security side, they were like, yeah, we use this, but we really need the transaction assertion, so you can actually state in your transaction what is the expected outcome of this transaction, and then other people, they were like, yeah, can we put this in the proposal as well, so this kind of, all these things always go on, and people just keep wanting more and more features, and we have to kind of see how we can compress all of this into this minimal

change that is actually shippable in a fork. So this is kind of what we ended up in the... Yeah, makes sense. So I think it's a good time to talk about the recent discourse around EIP-8141, the frame transaction. And also there was a big proposal called EIP-8130, proposed by Base and supported by multiple L2 teams. So as I understand, frame transactions, as you said, define a very general execution model that accounts can build on, while 8130 puts the account configuration,

about who can add, or how signatures are checked, or who pays, directly into a system contract. So many researchers and developers discussed how to align the two different proposals, but I think it unfortunately failed to reach an agreement. So Base is deploying EIP-8130 to Base, EIP-8141 will be shipped, maybe shipped in Hegotá, right? So, so I think Felix, you mentioned transaction assertions as a use case of frame transactions, and is there any other design that

can only be implemented in frame transactions and not in other proposals like EIP-8130? That's a good question. From the start we were saying we want to, we've been trying to preserve this property that in some ways it's about preserving permissionless innovation, in a sense. So we were always saying from the start, we cannot know what people will want to do with this mechanism once it's introduced. We just have to make sure that they can do whatever. But at the same time it is somewhat constrained, because obviously when it comes to... one of the difficulties with frame transactions is with the mempool.

So if you do want to send this transaction to the public mempool, then there will be some restrictions on it. And this means that in practice not everything that you could possibly do with the design will be realizable as a public mempool transaction. But there are things such as, one of the things is, for example, the transaction sponsored by the builder. We thought a lot about this, is it possible with frame transactions to have very elegant flows where the builder, who isn't really bound to the public mempool, can include transactions such that it covers the gas, for example. So these kinds of use cases we've been thinking about a lot.

But also, the other big thing is about, another big research direction that we went into is about the signature aggregation of transactions. Because with post-quantum, one key problem we were facing is that the post-quantum signatures are very large. So even we, when initially, when we started with frame transactions, we thought, yeah, okay, the user can just deploy some validation logic into their account and then they send this post-quantum signature with the transaction, and then the account will verify it and it's all good, we are post-quantum. But it's not as simple as that, because we cannot have every transaction carry like four kilobytes of

proof just to be included; it's impractical. So then we started thinking, well, at least on the block level we need to be able to actually compress the signatures and create some kind of aggregate. But then what do we do with the mempool? So now we're kind of going back and forth and trying to figure out how we can actually make this work on the mempool side, so we can do this pre-aggregation of the signatures, and it all gets very complex. But ultimately these kinds of directions we spend a lot more time on than thinking about stuff such as how people will actually in practice manage their keys. And so I think it's more like Base's proposal is much more on the side of, like, how can we do something very practical, but we see it as a bit,

I mean, a frame transaction is a superset of 8130. So it can do pretty much everything 8130 can do and more. So we just kind of see it like we want to do the bigger things. That makes sense. I want to ask a similar question to Taek. You've reviewed EIP-8130 closely through the lens of L2s, right? What was the, like, several L2s, including, like, Base, Optimism, and also, like, I think, Arbitrum, kind of, like, gave their support for that EIP.

So what was the main motivation for the L2s' support for that? What was the stance of blockchain regarding this issue? So, so regarding EIP-8130, I think the reason why we actually supported EIP-8130 and the reason why we still do is that it is just a matter of time. Time to market is a bit critical for L2s these days, because the fact that you have a feature that others don't is quite critical when you're onboarding a new protocol onto your rollup.

I think that's the main reason. I know that EIP-8130 has an account model that is not ideal. Having an account model in EIP-8130 is not ideal, and we are still discussing what to do with that. But although it is not ideal, it is a great solution for, I mean, while waiting for frame transactions to be live on L1. Because L1, I mean, frame transactions are quite too general.

I'm not saying it shouldn't be, but it's too general for engineers to adopt before L1 implements it. So we need something that works before frame transactions. And because Base is pushing it hard with the and, like, Optimism is also important. We really didn't want another fragmentation by, like, proposing a new proposal. So that's the main reason why we are on the support list. Thanks for the answer.

Yeah, so again, Felix just talked about why EIP-8141 is more optimal for Ethereum L1, and still there are some reasons from L2s that they want something before L1 implements frame transactions, so that's why EIP-8130 is still being supported by the L2s.

I want to ask about some glimpses of the future. Could you talk something about the world where we have both EIPs? We have EIP-8130 and EIP-8141. So you are developing a wallet, and you have to support two different transaction models. What actually changes for wallet devs in that world? I was actually more worried initially than now.

One of the reasons that I was worried is that I would expect that something works on some chains and on other chains it doesn't work. That is one of the reasons that I found it a risk. And for a wallet developer, they have to do a huge bunch of if-else routing for each chain, and also check if each chain is supporting something or not by doing some if-else or getting some getCode with the EIP-8141 and EIP-8130, and that will introduce a lot of latency on sending a simple transaction that it needs to do. And also for the smart contract

side, on the account side, it's not something that is not so lower It's just painful. I mean, we have to deal with different paths, and we have to make sure most paths are working properly, and some teams work on this and some teams work on that. But honestly, right now, if you ask me right now, I'm not really that worried, because in reality, people who want EIP-8130 type of UX are not the same people that use A1 program for transactions.

So, for example, A1 program for transactions are more focused on the privacy, and I mean, obviously, if L1 supports it, I mean, I'm quite confident that Base or any other L2s will start using EIP-8141 too, and also EIP-8130 on its side. And I think that will be the main use case for your whole asset, like your whole account, or maybe like your other account, then you do the daily device stuff.

But EIP-8130 is more focused on the UX flow, where the embedded accounts are done. And if you think about this, then it is a whole different flow and a whole different user type. There will be some overlap between EIP-8130 and EIP-8141. But in reality, I don't see that much. Yeah. That's my point. OK. That also makes sense. Felix, do you have any tips on that? The future of 2 EIPs coexisting? Yeah, so I think one thing that became kind of clear is that the key registry part of AD130 can be deployed on L1 still, and it can

also be utilized by the users. So they are not mutually exclusive in that way, because as I said before, the frame transaction approach doesn't really prescribe any kind of account model. It's just more the question of, if we do the key registry on L1, then who's gonna own it, for example. So I mean, for the L2s, that is very clear. There's a very clear answer, because L2s have an operator, so the operator is a somewhat privileged entity in the system, they can obviously own the registry, and they can also enable signature types in the registry, but we do not have this situation on L1, there is no operator.

So it's always difficult when we have this kind of specially authorized list that we have to update, so then we would have to figure out what is the process for enabling new signature types. This was a big part of these discussions with Base, that we just kept saying, well, I mean, how are you going to enable new signature types on 8130? And then they were like, yeah, I mean, I guess you have to do a hard fork. And then we're kind of back to the same thing: we want to ship something urgently, but we have to come together in an ACD every time just to make the special transaction to the registry.

That doesn't, we don't want to do that. So the mechanism has to be so general that it doesn't require any maintenance from our side. But that doesn't mean that there cannot be key registries like the EIP-8130, it's just a question of, if some companies can get together and figure out a registry together and host that process by themselves, then the users can send transactions that use this registry for validation, and then we're good. Good. So it's just that we cannot directly use it as is. Maybe the other comment I want to give is more about the past and not so much about the future.

It was a bit unfortunate that when 8130 entered the discussions, Base had already fully committed to shipping it, like, right now. Whereas for us it was pretty clear that the soonest account abstraction can ship on mainnet at all is with the H-star fork, which is in about a year, hopefully. So it's kind of the thing, from the start there was going to be this one-year delay where we're not going to have any kind of native account abstraction on mainnet, and you know, they came in and they were like, we want to do this now. So what should we do?

Should we just say we're going to do this in one year? So I guess there was, because the circumstances were pretty clear, that like, if they are so committed to shipping something right now, then yeah, they have to ship their own thing. Obviously they're not gonna ship some kind of beta version of frame transactions only to then later have to modify it or something. So then, you know. Yeah right. That makes sense. So I think the timing was kind of, like, not very good for about the shipping timing.

But I think, as you said, the two proposals can coexist in some way, so that we can bring the key registry of EIP-8130 to mainnet and so forth. So yeah, I think it's not that bad an outcome. So we are actually running out of time, so So did you have an hour? 30 minutes.

So here comes the last question. So we talked about the future, but what are you most excited about in the future of native account abstraction? For me it's become very interesting from a technical point of view with these PQ challenges, because we are really working on that now, and we have some solution now, like the official... I mean, the EF research side has been grinding pretty hard on this thing called leanVM, which is a purpose-built ZK architecture for signature aggregation, and we are leaning very heavily into hash-based signatures,

which is a kind of an appealing concept technically. Like, hash-based signatures are somewhat easy to understand, they are very, very simple from the fundamental side, but then actually shipping that in production, I mean, there aren't a lot of things built on hash-based signatures, because it comes with some amount of complexity with the production aspects, but I think it's quite exciting. If we manage to convert Ethereum execution to hash-based signatures, I think we're going to be good forever, basically. That is a very appealing thought to me, just to say I'm going to deploy this mechanism once and then that's just going to be for eternity.

And if you've been following the last two years of EF announcements, they're talking about the thousand years of Ethereum. So I guess whatever we build now has to last a thousand years, because the EF only has like, what, five more years of runway? So I guess... So we have five years to ship the thousand-year thing. So hash-based signatures are a pretty good bet in that regard. I'm actually a huge fan of frame transactions but while testing them out, I also realized that with frame transactions and with more EIPs that could come out after frame transactions,

I think it will be a whole different era of accounts. There will be better security, and there will be... I mean, honestly, I think it will change a lot of things on the user side, like how we interact with the account, and the concept of the account, and the concept of assets, and the concept of DeFi will change, because there are things that are enabled because of different frame structures. So yeah, I'm actually betting hard on what will be the next version of wallets after frame transactions. So yeah, I'm really sure about that.

So the future is bright. Thanks, guys, please give a round of applause to the audience.