Conversation ERC-4337 Author: Ethereum Account Abstraction and Evolution

Listen to the co-author of ERC-4337 talk about the cutting-edge and most crucial issues in account abstraction.

• Interviewees: Lucas and Jenny, Senior Research Manager and Senior Operations Manager of Huobi Incubator

• Interviewees: Kristof Gazso, Co-author of ERC-4337 and Praneeth Srikanti, Partner at Ethereal Ventures

• Translator: aididiaojp.eth, Foresight News

Host: Can each of you introduce yourselves first?

Kristof: I joined Nethermind in May 2021. Around November last year, I was thinking about what I would do next in this field and what the biggest bottleneck in this field is. The biggest problem I see currently is that ordinary people without a technical background face difficulties when using Ethereum applications. So, the most effective thing I can do is to solve the difficulties in using Ethereum accounts and wallets and improve the user experience of Ethereum applications.

There are two types of accounts: Externally Owned Accounts (EOA) and Smart Contract Accounts. Currently, users mainly use EOA accounts on Ethereum (such as Metamask and Rainbow), but they have certain limitations.

I have been looking for solutions and soon discovered the concept of account abstraction. I realized that there was no proposal that had a chance of being deployed on the mainnet because all previous proposals were either too complex or required too much work in terms of proposals. So, together with Vitalik and OpenGSN, we explored a solution for account abstraction, through which the mainnet would not need to undergo consensus-level protocol changes, and that is the main innovation of ERC-4337.

We can see that some applications are already being built. Currently, we are continuously developing the ecosystem and paving the way for the adoption of ERC-4337.

Praneeth: I am a Partner at Ethereal Ventures, a newly established crypto investment firm founded by the former risk investment team at ConsenSys.

In order to bring more people into Web3, we need to provide users with a lower threshold and smoother experience, which are typical conventions that people fundamentally expect, such as identity verification and social recovery.

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

Host: This year, the implementation of ERC 4337 regarding account abstraction was proposed, and we had several discussions on account abstraction during Devcon. ERC 4337 has actually become a popular term, despite the current market being very poor, we see some positive momentum surrounding accounts. So, first, can you explain what account abstraction is?

Kristof: Let me explain it in simple terms. In Ethereum, most people use externally owned accounts (EOA), which we call external owned accounts (EOA).

However, there is another type of account in Ethereum, which is a 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 many special permissions that smart contract accounts do not have. For example, only EOA accounts can initiate transactions, while smart contract accounts cannot initiate transactions.

In addition, EOA accounts work in a very procedural manner, so for EOA accounts, the way Gas payments work is that all the Gas you will use in the transaction is placed in the Ethereum smart contract, and if there is any leftover, it will be refunded to the account.

In EOA, signature verification is also very procedural, such as ECDSA signatures. This in itself is not a problem, but there is a lot of innovation available today in this solution.

So account abstraction is just an attempt to get rid of the idea of having only one account type and give smart contract accounts more power, allowing them to initiate transactions.

Praneeth: Account abstraction can bring more security and user-friendliness to Web3, which is what we hope users will experience when they first start interacting with blockchains. Considering how they need to store and remember their private keys without granting access to specific smart contracts to purchase tokens or services is a bad experience.

Account abstraction allows us to interact in a very intuitive way. People can use it to have precise control over key permissions, which is something people are used to using on Web2 accounts today.

We also need to fundamentally consider what the limitations of a given wallet's features are and try to see if we can transition from a transaction-based model to a consensus-based model.

Kristof: If we can transition well to smart contract wallets, here are a few examples of the powers users can gain beyond current functionalities.

One example is the Gas payment method. Dapps will be very easy to incentivize users to transact. Users can also use different tokens or even off-chain credit cards for payments, so transactions can be made without ETH. Now, any type of system or individual Gas payment method is possible.

With signature schemes, users can have social recovery schemes and multi-signature schemes, and can fully customize the behavior of their accounts and the types of permissions of sub-accounts.

The user's main account may be controlled by multi-signature and granted quick access through a private key, but only if it interacts with on-chain gaming contracts. With this setup, the user's wallet and on-chain games will be able to transact on behalf of the user, but with very limited permissions. In other words, users can fully define how individual accounts should behave with EVM/Solidity code, providing custom permissions such as time-based permissions, spending limits, etc.

One very common user experience issue is the lack of batch transactions. Users no longer need to approve and then swap on Uniswap (which is now 2 transactions), but users can now place any number of individual actions into the same transaction.

These improvements combined provide a truly powerful user experience for the next generation of crypto users. Users can essentially have the same experience as using NEO Banks.

Host: The Ethereum community is pushing for the implementation of EIP-4337, which comes after EIP-86, EIP-2938, etc. Why do we need a new account abstraction protocol standard? How will it affect the Ethereum development community and users?

Kristof: The most relevant proposal before was EIP-2938, which was founded by my friend Ansgar. EIP-2938 defines a mechanism for account abstraction based on Ethereum, which actually changes how Ethereum will operate. So why isn't it being maintained? The problem is that any kind of protocol-level change is a very difficult process. In the past year and a half, almost all the efforts of core developers have been focused on mergers, so core developers have no time to try to implement account abstraction proposals.

Account abstraction is very useful in UX terms, but its priority is not as high as scalability and security. Currently, resources are mainly allocated to mergers, withdrawals, and aspects such as EIP-4844 proto-danksharding and EVM, and the core developer community needs at least another 2-4 years to shift attention to improving user experience. That is why we decided to try to propose the new ERC-4337 proposal, which can be implemented with smart contracts deployed alongside Ethereum, without the need for deployment at the protocol level.

I think the reason the community did not adopt something like 2938 in the end is because account abstraction inherently introduces some potential denial of service risks. Through account abstraction, you can let the wallet define whether a transaction is valid, essentially you have to execute custom EVM code to determine whether the transaction is actually paid to the miner or validator. So introducing something similar directly into the consensus is a very big risk, and it's better to try first using ERCs rather 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, and it can be fully friendly in future protocols and guide other inventions.

Host: With account abstraction as the standard and contract wallets becoming the preferred choice, such as Gnosis Safe, Argent, etc., what features are now available and what features are expected to appear in the near future?

Kristof: It is important to note that Gnosis Safe and Argent are not yet compatible with ERC-4337. So ERC-4337 is just a standard that defines what account abstraction wallets and payers, and other parts of the ecosystem should look like.

Regarding your other question, what features have we seen and what features are we expecting in the future? In Argent, we have seen things like using ERC-20 tokens for payments. We have not seen very common Gas fee payment forms yet. This is definitely the future for Gnosis Safe and Argent. We have seen many differences in social recovery and multi-sig solutions, but we have not really seen the generation of sub-accounts and providing very customized permissions for sub-accounts.

I remember using Argent there was a feature where you could generate a signer key, which could act on your behalf to transact based on terms you specify. So you might go to your social recovery signers, you might ask them to approve a special key that can transact within a day, meaning you can execute a large number of transactions in sequence without having to return to your signers each time. So this is a basic example of what may happen in the future.

As far as I know, there are currently no introductions of spending limits or similar things, which I think are very important for the future user experience. Wallets like Argent and Gnosis Safe are not yet compliant with the standard, and once they are compliant, they will unlock many very cool features.

Praneeth: ERC-4337 still requires existing users to upgrade our control panel we have by transferring assets and activities to new accounts to comply with the ERC-4337 standard. In addition, there are other measures that need to be taken to ensure that the migration process can proceed smoothly and avoid introducing too much friction, especially for accounts that have not had much activity in the backend.

But beyond that, I think there is still this idea that we will keep EOA as the first choice, and we may see more features related to account abstraction, especially on L2, where people draw inspiration from 4337. The path to EOA migration accounts will also be a very interesting path, and there is hope for a breakthrough in the near future.

Kristof: Praneeth, you mentioned a very interesting topic, which is how we will actually transition EOA wallets to smart contract wallets in the future. This is a very important question, and many people I have talked to about smart contract wallets have a common reaction, which is that transferring everything to a new wallet is very troublesome, especially with soul-bound tokens.

So, we need to find a way to make EOA wallets into smart contracts. We have two main choices. One is a weaker version where we can introduce a new transaction type. This transaction type would simply convert your EOA into a smart contract account if you submit a transaction, for example, it would convert your EOA into a smart contract account based on the code you specify in the data field. You only need to call 1 transaction to define in a very fully customizable way what your account looks like using smart contract code. This will have the same address as all the tokens, all NFTs, or everything you had before.

The other option is a stronger version, which is not letting users choose to turn their EOAs into smart contract accounts, but once a hard fork happens, you can immediately turn every EOA into a very simple smart contract account, so this smart contract account will have the same features as what you have now. It will rely on ECDSA, which basically eliminates EOA.

This is an important trade-off we need to consider now, and we are likely to lean towards the second choice, trying to get a more powerful version. Because if you adopt the weaker version and allow people to turn their EOA into smart contract accounts, you will actually use more EOA. So you will have a transaction type whose only purpose is to convert EOA into a smart contract account. But what if you want to completely get rid of EOA in the future, so this is a future topic we are working on figuring out.

But as I mentioned before, any kind of consensus change attempt in Ethereum takes a long time to implement, like 1-3 years. So don't bet on getting rid of EOA quickly.

Praneeth: I absolutely agree with that. Furthermore, it changes some of these assumptions for application developers regarding EVM object formats, as it relates to contracts that typically rely on certain assumptions surrounding signature schemes, which basically indicate whether the signature is related to an EOA account.

But I think it will raise more questions, as it may boil down to forcing the potential old accounts to convert, and in a sense may not truly be able to detect accounts that have been inactive for many years. But I think, for those using EOAs, in accepting this, there may need to be some changes.

Host: If account abstraction is a game-changer and an essential default setting for our future crypto experiences, many other Dapps and infrastructure need to be built to make it work. For developers, what wallet support is needed, and how should Dapps plan ahead to design features based on smart contract wallets?

Kristof: There are two very simple answers. Dapps are expected to deploy and implement, and it is not too difficult. One is to stop discriminating against smart contract accounts, such as stopping the use of transaction origin. Once we have account abstraction, this will really create a lot of confusion in the future, even if you are using 457 now. If you use the transaction origin, it will also point you to Bundles, an ecosystem player that bundles user operations together. So, stop using the transaction origin, and do not prohibit smart contracts from interacting with your Dapps.

The second is to start being EIP-1271 compatible. This EIP defines a way for smart contract wallets to sign authorizations. So if the smart contract wallet implements the "if valid signature" feature and returns "true," you will treat it as if the wallet signed the message. But many Dapps still do not comply with this, they assume that an EOA account has a simple ECDSA signature to determine if it is signed. So I think these are two things. One, do not discriminate against smart contract accounts, two, comply with EIP-1271.

Praneeth: Yes, I think that is accurate. Just remember one thing, any changes around EVM object formats may enter the Shanghai upgrade.

As we consider a broader roadmap for proposals or builders' separations, and ensure that we have the ability to be considered by the core protocol, many works that are expected to happen, such as specialized U.S. sections, will be very important teams fundamentally because you are considering new mechanisms and models, such as proposals or builders' separation schemes.

But as long as you make sure you closely follow the EOF and EIPs, you will better understand the concepts of verification and execution in the protocol.

Host: Are we talking about account abstraction in the Ethereum ecosystem consisting of Layer2 and Layer3, or are we talking about account abstraction in a broader multi-chain ecosystem? Why is Layer2 the birthplace of account abstraction and not Ethereum? What is StarkNet currently working on regarding account abstraction?

Kristof: I can answer your first question, which is why we see the development of account abstraction in Layer2 with two words: Gas fees. With account abstraction, transactions are verified by smart contract code instead of by the node itself, which is the case with EOA.

Because Gas costs on Layer1 mainnet are much higher than on Layer2, the added Gas cost on Layer1 is much more penalizing. In Layer1, an EOA transaction might cost $10, while a smart contract wallet transaction might cost $20, which in Layer2 might only require one cent or two cents. Therefore, the Gas fee difference in Layer2 can be negligible, which is why we expect to see Layer2 appear before any specific adoption on Layer1.

As far as I know, StarkNet has many mechanisms inspired by ERC-4337. I am not very familiar with them, but they have already allowed for the deployment of smart contracts and the direct use of those contracts to initiate transactions. So they have implemented relevant contracts in a similar way to 4337, and they have been trying it out in their protocol. They have taken a big step forward, which is very encouraging.

Praneeth: Dan Finlay's delegation framework essentially has the ability to add counterfactual delegations to any solidity contract and account, including many functionalities related to smart contract wallets: with verification, with the ability to batch transactions. Using this framework as a basis, it allows EOA to act as smart contract wallets without having to deploy contracts off-chain by publishing messages. This is essentially the main work of EIP-3074 and EIP-5003.

But your signing keys are still associated with keys that users still need to back up. You can delegate permissions to any smart contract, but you will still encounter issues related to revoking and canceling permissions and node management. I think there are some very interesting concepts surrounding account abstraction, but it is done in a way that avoids protocol modifications. Some of these experiments can even look at whether this is a method that can be used for data migration for most EOA accounts.

We would encourage people to take some time to look at the delegation framework that has been tested for a while.

Audience Question (Eric Siu): What are your thoughts on 4337 compared to other EIPs like 3074 and 5003 for account abstraction?

Kristof: 3074 came earlier than any EIP for accounts. Its role is to give EOA accounts more power. So it introduces the concept of invokers, and basically allows the invoker to represent the EOA to transact under some restrictions it can define.

There are two issues, which are also why it may not enter the mainnet or not. The first issue is that it serves EOAs, making EOAs more powerful. This is good because if you want to use the functionalities of a smart