Dialogue with ERC-4337 author: Ethereum account abstraction and its evolution
Interview: Lucas, Jenny, Senior Research Manager and Senior Operations Manager of Huobi Incubator
Compilation: aididiaojp.eth, Foresight News
Compilation: aididiaojp.eth, Foresight News
Moderator: Can you introduce yourself first?
Kristof：I joined Nethermind in May 2021, around November last year, I was thinking about what I would do next in this field, what is the biggest bottleneck facing this field? The biggest problem right now is seeing how difficult it is for ordinary people without a technical background to use Ethereum applications. So for me, the most effective thing I can do is to solve the difficulty 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. Now on Ethereum, users mainly use EOA accounts (such as Metamask and Rainbow), but they have certain restrictions.
I've been looking for a solution for a while and found the concept of account abstraction. I realize that no proposal has had a chance to be deployed to mainnet yet because all previous proposals were either too complex or required too much work on the proposal. So together with Vitalik and OpenGSN, we explore the solution of account abstraction, through which, the main network does not need to make consensus level protocol changes, and this is the main innovation point of ERC-4337.
We can see that some applications are being built so far. Now, we are constantly developing the ecology and paving the way for the popularization of ERC-4337.
Praneeth：I'm an investment partner at Ethereal Ventures, a new crypto investment firm founded by the ex-VC team at ConsenSys.
To get more people into Web3, we need to provide users with a lower barrier to entry and a smooth experience, typical conventions that people are fundamentally used to, such as authentication and social restoration.
Through account abstraction, it is able to provide an efficient solution 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.
Moderator: ERC 4337 on implementing account abstraction was proposed this year, and we had several discussions on account abstraction during Devcon. ERC 4337 has actually become a buzzword, and although the current market is very bad, we have seen some good momentum around account accounts. So first of all, can you explain what is account abstraction?
Kristof：Let me first explain in layman's terms. In Ethereum, the accounts used by most people are private key accounts, and we call these accounts externally 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 codes.
The problem is that in Ethereum, EOA accounts have many special permissions that smart contract accounts do not. For example, only EOA accounts can initiate transactions, while smart contract accounts cannot initiate transactions.
Also, EOA accounts are very procedural in the way they work, so for EOA accounts, the way Gas payment works is that you put all the Gas used in the transaction in the Ethereum smart contract, and if there is any left, it will refunded to the account.
In EOA, signature verification is also very procedural, such as ECDSA signatures. There's nothing wrong with that in itself, but we have a lot of innovation in this scheme that can be used today.
So account abstraction is just trying to get rid of the concept of only one type of account, and provide more power to smart contract accounts, giving them the power to initiate transactions.
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. Considering how they need to store and remember their private keys without granting access to a specific smart contract to purchase tokens or services is a bad experience.
The account abstraction allows us to interact in a very intuitive way. People can use this to have fine-grained control over key permissions, which is what people use today on Web2 accounts.
We also need to fundamentally think about what the limiting functionality 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 smart contract wallets, here are a few examples of the power users can gain on top of current functionality.
An example is the gas payment method. Dapps will very easily gain the ability to incentivize user transactions. Users can also pay with different tokens or even credit cards off-chain, so no ETH is required for transactions. Any type of system or individual gas payment method is now possible.
With signature schemes, users can have social recovery schemes and multi-signature schemes, and can fully customize how accounts behave and the types of permissions for sub-accounts.
A user's master account may be controlled by a multi-signature and grant quick 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 permissions. In other words users can fully define how a personal account should look like using EVM/Solidity code, and you can provide custom permissions such as time-based permissions, spending limits, etc.
A final and very common UX issue is missing batch transactions. Instead of having to approve and then Swap on Uniswap (2 transactions now), users can now put any number of separate operations into the same transaction.
Together, these improvements provide a truly powerful user experience for the next generation of crypto users. Users can basically have the same experience as using NEO Banks.
Moderator: The Ethereum community is advancing the implementation of EIP-4337, which was launched after EIP-86, EIP-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 EIP-2938, created by my friend Ansgar. EIP-2938 defines an account abstraction mechanism based on Ethereum, which is actually a protocol that changes how Ethereum will work. So why not maintain it now? The problem is that any kind of protocol level change is a very difficult process. Almost all core dev effort over the past year and a half has gone into the merge, so the core devs haven't had time to try and 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, currently resources are mainly allocated to mergers, withdrawals, and EIP-4844 proto-danksharding and EVM, etc., and the core developer community is still at least It will take 2-4 years to shift focus to improving the user experience. That's why we decided to try to come up with a new ERC-4337 proposal, which can be implemented through smart contracts deployed with Ethereum, without the need for deployment at the protocol level.
I guess the ultimate reason the community didn't adopt something like 2938 is because the account abstraction inherently introduces some potential denial of service risk. With the account abstraction, you let the wallet define whether the transaction is valid, basically you have to execute custom EVM code to determine whether the transaction actually pays the miner or validator. So it's a very big risk to introduce something like that directly into consensus, and it's better to try to use ERC first than actually change 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 the future protocol and serve as a bootstrap for other inventions.
Moderator: Taking account abstraction as the standard, contract wallets become the first choice, such as Gnosis Safe, Argent, etc. So which functions are popular now, and which functions are expected to appear in the near future?
Kristof：The first thing to note is that Gnosis Safe and Argent are not yet ERC-4337 compliant. 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, which features have we seen and which features are we looking forward to in the future? In Argent we've seen things like payments with ERC-20 tokens. We haven't seen a very common form of gas fee payment yet. This is definitely the future of Gnosis Safe and Argent. We've seen a lot of variance in scenarios like social recovery and multi-sync, but we haven't really seen subaccount generation and giving subaccounts very custom permissions.
I remember using Argent there was a feature where you could generate a signer key that could transact on your behalf under your stated terms. So you might go to your social recovery signers, you might ask them to approve a special key that can transact for a day, which means you can execute a lot of transactions in sequence without having to return to you every time of the signers. So this is already a basic example of what might happen in the future.
As far as I know, there is no such thing as a spending limit introduced yet, which I think is very important for the user experience going forward. Wallets like Argent and Gnosis Safe are not yet compliant, and once they do, they will unlock a lot of really cool features.
Praneeth：ERC-4337 still requires existing users to upgrade the consoles we have to be ERC-4337 compliant by transferring assets and activity to new accounts. Beyond that, there are a few other things that need to come into play to make sure the migration process can go smoothly and avoid introducing too much friction, especially for accounts that don't have much activity in the background.
But beyond that, I think there's still the idea that we're going to have EOA always be the first choice, and we'll probably see more account abstraction-related features come into play, especially as people take inspiration from 4337 on L2. Getting a path to EOA Migration Accounts would also be a very interesting one, and hopefully a breakthrough in the not-too-distant future.
Kristof：Praneeth, you brought up a very interesting topic about how exactly we migrate EOA to smart contract wallets in the future. This is a very important question, and a common reaction from many people I've talked to about smart contract wallets is that it's a hassle to move everything to a new wallet, especially soulbound tokens.
Therefore, we have to find a way to make the EOA wallet into a smart contract. We have two main options. One is a weaker version where we can introduce a new transaction type. What this transaction type enables is that if you submit a transaction, it simply converts your EOA into a smart contract account, for example according to the code you specify in the data field. You only need to call 1 transaction to define what your account looks like using smart contract code in a very completely custom way. This will be the same address as all the tokens you previously owned, all the NFTs or whatever.
Another option is a stronger version where instead of giving users the option to turn their EOA into a smart contract, once the hard fork happens, you can instantly turn each EOA into a very simple smart contract account, So this smart contract account will be the same scheme as you have now. It will rely on ECDSA, which basically gets rid of EOA in one fell swoop.
This is an important tradeoff we need to consider now, and we will likely lean towards the second option in an attempt to get a more powerful version. Because if you take a weaker version and allow people to turn EOA into a smart contract account, you will actually use EOA more. Therefore, you will have a transaction type whose sole purpose is to convert 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 topic that we're trying to figure out.
But as I said before, trying to introduce any kind of consensus change to Ethereum will take a long time to implement, say 1-3 years. So definitely don't bet on getting rid of EOA anytime soon.
Praneeth：I absolutely agree with this. Also, it changes these assumptions for application developers, as it relates to contracts that typically rely on certain assumptions around signature schemes that basically say whether that signature is related to an EOA account or not.
But I think this raises more questions because it could come down to casting accounts that might be old, and in a sense it might not really be able to detect accounts where people haven't had any activity in years. But I think for people who use EOA, there may be some changes in terms of acceptance.
Moderator: If account abstraction is a game-changer and an integral default for our future crypto experiences, many other Dapps and infrastructure will need to be built to make it work. For developers, what wallet support is required, and how can Dapps plan ahead to design functionality based on smart contract wallets?
Kristof：There are two very simple answers, Dapps promise to be deployed, and it's not too hard. One is to stop discriminating against smart contract accounts, such as 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 transaction sources, it also points you to Bundles, an ecosystem player that bundles user actions together. So, stop using transaction sources and don't disable smart contracts from interacting with your Dapps.
The second is to become compatible with EIP-1271. This EIP defines a method for signing authorizations with smart contract wallets. So, if the smart contract wallet implements the "if valid signature" function and returns "true", then you will treat it as if the wallet signed the message. But many Dapps still don't conform to this, they assume the EOA account has a simple ECDSA signature to determine if it is signed. So I guess it's two things. One, do not discriminate against smart contract accounts, and two, comply with EIP-1271.
Praneeth：Yes, I think that's pretty accurate. Just one thing to keep in mind, all changes around the EVM object format may make it into Shanghai upgrades.
A lot of the work that is expected to happen, like a dedicated US part, will be fundamentally very important as we look at the broader proposal or long-term roadmap for builders separation and making sure we have the ability to be considered by the core agreement, Because you're considering new mechanics and models, like proposals to play or builder separation schemes.
But just make sure you pay close attention to EOF and EIP so you can better understand the concepts of validation and enforcement in the protocol.
Moderator: Are we only talking about account abstraction in the Ethereum ecosystem consisting of Layer 2 and Layer 3, or are we talking about account abstraction in the broader multi-chain ecosystem? Why is Layer 2 the birthplace of account abstraction instead of Ethereum? What is StarkNet's current work on developing account abstractions?
Kristof：I can answer your first question, which is why we look at the development of account abstraction in Layer 2 with two words: gas fees. With account abstraction, rely on smart contract code to verify that your transactions are valid. But with EOA, this is verified by the nodes themselves.
Since the Gas cost of the Layer 1 main network is much higher than that of Layer 2, the gas cost penalty added in Layer 1 is much greater. At layer 1, an EOA transaction might cost $10, while a smart contract wallet transaction might cost $20, which at layer 2 might only cost a penny or two. As such, gas fee differences in Layer 2 are negligible, which is why we expect to see Layer 2 appear before any particular Layer 1 adoption.
As far as I know, StarkNet has many mechanisms inspired by ERC-4337. I'm not very familiar with them, but they already allow deploying a smart contract and directly using that contract to initiate a transaction. So they implement related contracts in a similar way to 4337, and they've tried that in their protocol. They've taken a big step forward, which is very inspiring.
Praneeth：Dan Finlay's delegation framework, which essentially has the ability to add counterfactual delegation to any solidity contract and account, includes many features related to smart contract-based wallets: with verification, with the ability to batch transactions. Using this framework as a basis allows EOA to act as a smart contract wallet without deploying contracts by publishing messages off-chain. This is basically the main work of EIP-3074 and EIP-5003.
But your signing key is still associated with a key that users still need to back up. You can delegate permissions to arbitrary smart contracts, but you still run into issues related to revocation and cancellation of permissions and node management. I think there are some really interesting concepts around account abstraction, but in a way that avoids protocol modifications. Use some of these experiments to even see if this is a method that can be used for data migration for most EOA accounts.
We would encourage people to spend some time looking at the delegable frameworks that have been around for a while.
Audience question (Eric Siu): What do you think about the account abstraction of 4337 versus other EIPs like 3074 and 5003?
Kristof：3074 predates any account EIP. Its role is to give more power to the EOA account. So it introduces the concept of a caller and basically allows that caller to transact on behalf of the EOA subject to some constraints it can define.
This has two problems and is why it probably won't make it to mainnet. The first problem is that it serves the EOA and makes the EOA stronger. This is good because you don't have to move your balance anymore if you want to use the smart contract wallet functionality, but it's also bad because there are a lot of technical issues if you want to introduce account abstraction in the future.
The second problem is that it has some security issues with Invokers. Granting full access to the caller can cause some weird side effects. Yoav Weiss is a co-author of 4337 and he published many of the security issues with 3074, I recommend people check out his post outlining the security issues. So I guess that's why this EIP is unlikely to make it to mainnet.
Audience question (Ric Burton): I'm really curious what people on stage think might happen in the future with all this starting to play out. I think right now we're focusing on implementation details and how to make Dapps developers aware of all these things. I'm wondering what your future dreams would be if all of this were to come true in five years, and are there any matching apps, products, tools, or services?
Kristof：For me, my vision is that once we actually have a good account abstraction ecosystem, operating rewards on Ethereum will be as easy or simpler than using any kind of NEO Bank that we have now. I can easily transfer any asset to a friend. I can use many of the built-in apps for saving and budgeting, but with very limited permissions, such as blocking my credit cards and doing those things. I really think that once our wallets take advantage of many of the features of account abstraction, we will be able to interact with the on-chain ecosystem 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's the ability for users to express their intent and have it executed automatically or in an automated conversation between applications and protocols, we abstract this combined consensus Intrinsic transactions are called abstract accounts. When you're interacting with these protocols, people need to use technologies or tools that can do that without really getting into the implementation details of how to do this in a practical way. So I think the ability to compose things together; assign multiple unstalled actions; the ability to sign commitments that can later be easily committed to the blockchain; and the ability to essentially have a core separation between verification and execution, etc. All things to think about.
Original link
