Account Abstraction (ERC-4337)
In this course, we will learn about a relatively new Ethereum proposal called ERC-4337 - the account abstraction standard. It's important to note that this proposal is in the draft stage as of the time of writing this, but there are several implementations of it already.
What is ERC-4337?
ERC-4337 is a specification that aims to achieve account abstraction through a single entry point.
In order to truly grasp the concept, we will have to take a look at the current state of Ethereum accounts and submitting transactions.
Ethereum Accounts
Currently, wallets implement EOA accounts. EOA stands for Externally Owned Account. These accounts are controlled by a private key and are used to sign transactions. The private key is used to generate a public key, which is then hashed to generate the address. The address is what is used to identify the account on the blockchain.
There are several drawbacks to this:
- Single point of failure - if the private key is lost, the account is lost forever
- Security risk - if the private key is compromised, the account could be drained of all funds
- Lack of flexibility - EOAs can only be controlled by a single private key with no room for flexible permissions
Submitting transactions
When transactions have been signed, they are submitted to the network with a gas fee. At the moment, the account signing the transaction is paying the gas fee. This means that in order to submit a transaction, you have to have ETH in your wallet.
The drawbacks are:
- Some users may not have ETH in their wallet to pay for gas fees.
- Some users may not be crypto-savvy enough to understand the concept of gas fees.
- Some users may have ERC-20 tokens in their wallet, but no ETH to pay for gas fees.
ERC-4337
ERC-4337 aims to solve these problems by introducing an Entry Point Contract to achieve account abstraction. Account abstraction in this case means that the account is no longer controlled by a private key, but rather by a smart contract. This smart contract can be controlled by multiple private keys, or even other smart contracts. Together with paymasters, this allows the proposal to solve the problems mentioned above.
- It allows for arbitrary account verification.
- It allows for flexible permissions. For example, an access key can be generated that only allows a user to perform a specific action.
- It allows for flexible gas payment. For example, a user can pay for gas fees using ERC-20 tokens instead of ETH.
- It allows for flexible account recovery. For example, a user can recover their account using a recovery.
- It allows account owners to create accounts without having to pay for gas fees, and in turn allowing for increased anonymity and adoption.
How does it work?
Below are the moving parts of ERC-4337:
User
When a user creates a transaction, a psuedo-transaction object is created called a UserOperation.
Bundler
A Bundler is a smart contract that is responsible for packaging UserOperations from a mempool and sending them to the Entry Point contract.
Entry Point Contract
An Entry Point Contract is a smart contract that is responsible for verifying UserOperations against the Account Contract. It's also responsible for executing the transaction logic.
Account Contract
This is the new smart contract wallet of the user. It's responsible for verifying signatures and processing transactions.
Account Factory Contract
This is a smart contract that is responsible for creating new Account Contracts. This smart contract should use the CREATE2 opcode to create new contracts deterministically.
CREATE2 is an opcode that allows you to create a contract at a deterministic address. This means that you can create a contract at an address that is known ahead of time.
Paymasters
These contracts are optional smart contract accounts that can be used to sponsor gas fees for Account Contracts, or allow Account Contracts to use ERC-20 tokens to pay for gas fees.
This image is embedded from
ERC4337.io - Understanding ERC-4337
Conclusion
ERC-4337 is a very interesting proposal that aims to solve some of the problems that we currently face with ethereum accounts and transactions. Once again, it's important to note that this proposal is still in the draft stage, but there are several implementations of it already.