Partnered With:

Conversation ERC-4337 Creator: Ethereum Account Abstraction and Evolution

Read this article in 30 Minutes

ERC-4337 Two co-creators talk about the cutting edge and most critical issues of account abstraction.

Interview: Lucas and Jenny, Senior research Manager and Senior Operations Manager of Huobi Incubator respectively

Interviewees: Kristof Gazso, co-author of ERC-4337, and Praneeth Srikanti, investment partner at Ethereal Ventures

aididiaojp.eth, Foresight News

Host: Can you introduce yourself first?

Kristof:I joined Nethermind in May 2021, and around November of last year I was thinking about what I want to do next in this space, and what are the biggest bottlenecks facing this space? The biggest problem right now is seeing how difficult it is for ordinary people with no technical background to use Ethereum applications. So for me, the most effective thing I can do is solve the problems of using Ethereum accounts and wallets, and improve the user experience of Ethereum applications.

There are two types of accounts: Private Accounts (EOA) and smart contract accounts. Right now on Ethereum, users are primarily using EOA accounts (such as Metamask and Rainbow), but they have certain limitations.

I was looking for a solution and soon discovered the concept of account abstraction. I realize that no proposal has had a chance to be deployed to Mainnet yet because all the previous proposals were either too complex or required too much work on the proposal. So together with Vitalik and OpenGSN, we are exploring an account abstraction solution that eliminates the need for consensus level protocol changes on the mainnet, which is the main innovation of ERC-4337.

We can see some applications being built so far. Now, we are developing the ecology and paving the way for the popularization of ERC-4337.

Praneeth:I am an investment partner at Ethereal Ventures, a new crypto investment company founded by the former venture capital team at ConsenSys.

In order to get more people into Web3, we need to provide users with lower barriers to entry and smoother experiences, typical conventions that people are used to fundamentally, such as authentication and social recovery.

Through account abstraction, it can provide efficient solutions to these problems. I am very interested in seeing the evolution of ERC-4337 and working with people and stakeholders in the ecosystem to witness its birth.

Host: ERC 4337 was introduced this year to implement account abstraction, and we had several discussions about account abstraction during Devcon. ERC 4337 has actually become a buzzword, and despite the current very bad market, we are seeing some good momentum around account accounts. So can you first explain what account abstraction is?

Kristof:Let me explain it in general terms. In Ethereum, the accounts most people use are private key accounts, which we call external ownership Accounts (EOAs).

However, there is another type of account in Ethereum, the smart contract account. EOA accounts are controlled by private keys, while smart contract accounts are controlled by their code.

The problem is that in Ethereum, EOA accounts have special privileges that smart contract accounts do not. For example, only EOA accounts can initiate transactions, but smart contract accounts cannot initiate transactions.

Also, EOA accounts are very programmatic in the way they work, so for EOA accounts, the way Gas payments work is that you put all the Gas you use in a transaction in an Ethereum smart contract, and if there is anything left over, it is only returned to the account.

In EOA, signature verification is also very programmatic, such as ECDSA signatures. There's nothing inherently wrong with that, but we have a lot of innovations in this scheme that we can use today.

So account abstraction simply tries to give smart contract accounts the power to initiate transactions by getting rid of the idea that there is only one type of account and giving them more power.

Praneeth:Account abstraction can introduce more security and user friendliness to Web3, which is how we want users to feel when they first start interacting with the blockchain. The experience of thinking about how they need to store and remember their private key without granting access to a specific smart contract to buy a token or service is a bad one.

Account abstraction enables us to interact in a very intuitive way. People can use it to have precise control over key permissions, which is what people use on their Web2 accounts today.

We also need to fundamentally think about what the limiting function of a given wallet is, and try to see if we can move from a transaction-based model to hopefully a consensus-based model.

Kristof:If we make a good transition to a smart contract wallet, here are a few examples of the power that users can get on top of their current capabilities.

One example is the Gas payment method. Dapps will easily gain the ability to incentivize user transactions. Users can also pay with different tokens or even off-chain credit cards, so transactions can be made without ETH. Any type of system or personal Gas payment method is now possible.

With the signature scheme, users can have both the social recovery scheme and the multi-signature scheme, and can fully customize the behavior of the account and the permission types of the sub-accounts.

A user's master account may be controlled by multiple signatures and granted fast access via a private key, but only if it interacts with an on-chain game contract. With this setup, user wallets and on-chain games will be able to transact on behalf of the user, but with very limited rights. In other words, users can use the EVM/Solidity code to fully define how personal accounts should be. You can provide custom permissions such as time-based permissions, spending limits, etc.

A final, very common user experience problem is the lack of volume transactions. Instead of the user having to approve and then do a Swap on Uniswap (now 2 transactions), the user can now put any number of individual operations into the same transaction.

Together, these improvements provide a truly powerful user experience for the next generation of encryption users. Users can basically have the same experience as they would with NEO Banks.

Host: The Ethereum community is pushing for the implementation of IP-4337, which was introduced after IP-86, IP-2938, etc. Why do we have a new account abstraction protocol level standard? What is the impact on the Ethereum development community and users?

Kristof:The most relevant previous proposal was IP-2938, which was created by my friend Ansgar. Ip-2938 defines an Ethereum-based account abstraction mechanism that actually changes the protocol for how Ethereum will operate. So why not do maintenance now? The problem is that any kind of protocol-level change is a very difficult process. Almost all of the core developers' efforts over the past year and a half have been focused on merging, so the core developers have not had time to try to implement the account abstraction proposal.

Account abstraction is very useful in UX terms, but it is not as high a priority as scalability and security. Resources are currently allocated to merge, withdraw, and IP-4844 proto-danksharding and EVM. And it will take at least two to four years for the core developer community to shift its focus to improving the user experience. That's why we decided to try to come up with a new ERC-4337 proposal that could be implemented through smart contracts deployed with Ethereum, without having to deploy at the protocol level.

I think the ultimate reason the community hasn't adopted something like 2938 is because account abstraction inherently introduces some potential denial of service risk. With account abstraction, you can let the wallet define whether the transaction is valid or not, basically you have to execute custom EVM code to determine if the transaction is actually paid to the miner or validator. Therefore, it is a very big risk to introduce something like this directly into the consensus, and it is better to try using ERC first than actually changing the node service.

Praneeth:I think this is a very good way for the 4337 ecosystem to start in a similar EVM-compatible environment, which can be completely friendly in future protocols and serve as a guide for other inventions.

Host: Contract wallets such as Gnosis Safe, Argent, etc. are the first choice based on account abstraction. What features are available now and what are expected to be available in the near future?

Kristof:The first thing to note is that Gnosis Safe and Argent are not yet compatible with ERC-4337. So ERC-4337 is just a standard that defines what the account abstract wallet and payer and the rest of the ecosystem should look like.

On your other question, what features have we seen and what can we expect in the future? In Argent, we've seen things like using ERC-20 tokens for payment. We haven't seen a very common form of Gas payment. This is definitely the future for Gnosis Safe and Argent. We've seen a lot of differences in schemes like social recovery and multi-synchronization, but we haven't really seen the generation of child accounts and very custom permissions for child accounts.

I remember that with Argent there is a feature where you can generate a signer key that can transact on your behalf according to your stated terms. So you might go to your social recovery signer, and you might ask them to approve a special key that can be traded within a day, which means you can execute a lot of transactions sequentially and not have to go back to your signer every time. So this is already a basic example of what could happen in the future.

As far as I know, nothing like a spending limit has been introduced, which I think is very important for the user experience in the future. Wallets such as Argent and Gnosis Safe have yet to meet the criteria, and when they do, they will unlock a lot of really cool features.

Praneeth:ERC-4337 still requires existing users to upgrade the console we have to ERC-4337 standards by transferring assets and activities to a new account. Beyond that, there are a few other measures that need to come into play to ensure that the migration process goes smoothly and to avoid introducing too much friction, especially for accounts that don't have much activity behind the scenes.

But beyond that, I think there's still the idea that we're going to let EOA always be the first choice, and we're likely to see more features related to account abstraction come into play, especially on L2 where people draw inspiration from 4337. Access to EOA migration accounts will also be a very interesting route and hopefully a breakthrough will be achieved soon.

Kristof:Praneeth, you brought up a very interesting topic of how exactly we can migrate EOA to smart contract wallets in the future. This is a very important issue, and a common response from many people I've talked to about smart contract wallets is that they find it cumbersome to move everything to a new wallet, especially soul bound tokens.

So, we need to find a way to make EOA wallets into smart contracts. We have two main options. One is a weaker version where we can introduce a new type of transaction. What this type of transaction enables is that if you submit a transaction, it will simply convert your EOA into a smart contract account, for example according to the code you specify in the data field. With just one transaction, you can define how your account looks with the smart contract code in a very completely custom way. This will be the same address as all the tokens, all the NFT, or everything you had before.

The other option is a stronger version where instead of giving users the option to turn their EOA into a smart contract, as soon as a hard fork happens, you can immediately turn each EOA into a very simple smart contract account, so that smart contract account will be the same scheme you have now. It will rely on ECDSA, which basically gets rid of EOA at a stroke.

This is an important trade-off we need to consider now, and we will most likely gravitate toward the second option to try to get the stronger version. Because if you take a weaker version and allow people to turn their EOAs into smart contract accounts, you actually use your EOAs more. Therefore, you will have a type of transaction whose sole purpose is to convert the EOA into a smart contract account. But what if in the future you want to get rid of EOA completely, so that's a future theme that we're trying to figure out.

But as I said before, any type of consensus change that attempts to introduce Ethereum would take a long time to implement, say 1-3 years. So don't bet on getting rid of EOA any time soon.

Praneeth:I absolutely agree with that. In addition, it changes these assumptions of the application developer because it relates to contracts that typically rely on certain assumptions around the signature scheme that basically indicate whether or not the signature is relevant to the EOA account.

But I think it raises more questions because it probably boils down to a cast on accounts that may be old, and in a sense may not really detect accounts where people haven't done any activity for years. But I think for people who use EOA, there may be some changes that need to be made in terms of acceptance.

Host: If account abstraction is a game changer and an integral default setting for our future encryption experience, many other Dapps and infrastructure need to be built to make it work properly. What wallet support is needed for developers, and how can Dapps plan ahead to design the functionality of a smart contract-based wallet?

Kristof:There are two very simple answers. Dapps promise to be deployed, and not too hard. One is to stop discriminating against smart contract accounts, such as by stopping the use of transaction sources. Once we have the account abstraction, this will indeed be very misleading in the future, even with 457 now. If you use a transactional source, it also points you to Bundles, an ecosystem player that bundles user operations together. Therefore, stop using transaction sources and do not prohibit smart contracts from interacting with your Dapps.

Second, it is compatible with IP-1271. This EIP defines a way to sign a license with a smart contract wallet. So, if the smart contract wallet implements the "if valid signature" function and returns "true," then you treat it as if the wallet signed the message. But many Dapps still don't meet this, assuming that the EOA account has a simple ECDSA signature to determine whether it is signed or not. So I guess those are the two things. One, don't discriminate against smart contract accounts, and two, abide by IP-1271.

Praneeth:Yes, I think that's accurate. Just keep one thing in mind, all the changes around the EVM object format are likely to make it to the Shanghai upgrade.

As we look at the broader proposal or the long-term roadmap for builder separation and make sure that we have the ability to be considered by the core agreement, a lot of the work that will hopefully take place, such as the dedicated US segment, will fundamentally be very important to the team as you look at new mechanisms and models, such as proposals that come into play or builder separation scenarios.

But just make sure you pay close attention to EOF and EIP, and you'll have a better understanding of the concepts of validation and execution in the protocol.

Host: Do we only talk about account abstraction in the Ethereum ecosystem, which consists of Layer2 and Layer3, or do we talk about account abstraction in the broader multi-chain ecosystem? Why is Layer2 the home of account abstraction and not Ethereum? What is StarkNet currently doing in developing account abstractions?

Kristof:I can answer your first question, which is why we view the development of account abstraction in Layer2 in two words: Gas fees. Through account abstraction, rely on smart contract code to verify that your transaction is valid. But with EOA, this is validated by the node itself.

Because the main network Gas cost of Layer1 is much higher than that of Layer2, the increased Gas cost penalty in Layer1 is much greater. At the first level, an EOA transaction might cost $10, while a smart contract wallet transaction might cost $20, compared to a penny or two on Layer2. Therefore, the difference in Gas rates in Layer2 is negligible, which is why we expect to see Layer2 before any particular Layer1 adoption.

As far as I know, StarkNet has many mechanisms inspired by ERC-4337. I'm not familiar with them, but they already allow smart contracts to be deployed and used directly to initiate transactions. So they implement the contracts in a similar way to 4337, and they've tried that in their agreements. They took a big step forward, which is very encouraging.

Praneeth: Dan Finlay's delegation framework, which essentially has the ability to add counterfactual delegation to any solidity contracts and accounts, includes many of the features associated with smart contract-based wallets: the ability to validate, the ability to trade in bulk. Using this framework as a foundation allows EOA to act as a smart contract wallet without deploying contracts by publishing messages down the chain. This is basically the main job of IP-3074 and IP-5003.

But your signing key is still associated with the key that the user still needs to back up. You can delegate permissions to any smart contract, but you'll still run into issues related to revoking and canceling permissions and node management. I think there are some very interesting concepts around account abstraction, but in a way that avoids protocol modification. Use some of these experiments to even see if this is a way to migrate data for most EOA accounts.

We would encourage people to spend some time looking at delegable frameworks that have been trialled for some time.

Audience Question (Eric Siu) : What do you think of the account abstractions between 4337 and other EIP such as 3074 and 5003?

Kristof: 3074 predates any account EIP. What it does is give more power to EOA accounts. So it introduces the concept of a caller and basically allows that caller to transact on behalf of the EOA with some limitations that it can define.

There are two problems with that and it's why it probably won't make it to the main net. The first problem is that it serves EOA and makes EOA stronger. This is good because you no longer have to transfer your balance if you want to use the functionality of a smart contract wallet, but it's also bad because there are a lot of technical issues if you introduce account abstractions in the future.

The second problem is that it has some security issues with Invokers. Granting full access to callers can lead to some strange side effects. Yoav Weiss is the co-author of 4337 and has published many of the security issues of 3074. I recommend that people check out his post outlining the security issues. So I think that's why this EIP is unlikely to make it to the main net.

Audience QUESTION (Ric Burton) : I'm really curious what the people on stage think might happen in the future when all this comes into play. I think right now we're focusing on the implementation details and how to get Dapps developers to know all these things. I'd like to know if all of this is realized in five years, what are your future dreams and if there are any matching apps, products, tools or services?

Kristof:For me, my vision is that once we really have a good ecosystem of account abstractions, running rewards on Ethereum will be as easy or simpler than using any type of NEO Bank we have today. I can easily transfer any asset to a friend. There are many built-in apps I can use to save and budget, but with very limited permissions, such as blocking my credit card and performing these actions. I really think that once our wallets take advantage of many of the features of account abstraction, we'll be able to interact with the on-chain ecosystem just as easily as we interact with our banks in the off-chain ecosystem.

Praneeth:I touched on this very briefly before, but in the sense that it is the ability of users to express their intentions and execute them automatically or in automated sessions of applications and protocols, the transactions inherent in our abstracting out this composite consensus are called abstract accounts. When you interact with these protocols, people need to use techniques or tools that can do this without really getting bogged down in the implementation details of how to do this in a practical way. So I think the ability to put things together; Assign multiple unstalled actions; The ability to sign commitments that can be easily submitted to the blockchain later; And the ability to fundamentally separate the core between validation and execution are things to think about.

Basically, this means being able to expose more fine-grained things related to access and authorization. Users are often used to using the very mature Web2 platform of today's world, but having these capabilities actually implemented or written into the protocol, and being able to adapt them through familiar user processes, will be very helpful in increasing the adoption rate of the Web3 platform.