The EIP inventory behind the account abstraction

By Vasa, co-founder of OpenSea Pro; Translation: Golden Finance Xiaozou

In this article, we’re going to take a quick look at the different EIPs that brought us to today’s account abstractions.

! [IBi1wWpT0680RWZaqv5DB56VCs7bGvDrkaHl3Wky.png] (https://img.jinse.cn/7122936_watermarknone.png “7122936”)

**1. Why do we need Account Abstraction (AA)? **

People like to throw questions like, “How do we bring the next billion users to Web3?” "There are many hurdles to overcome, but the most important of them is the user experience.

The following diagram is a typical user experience for a new user. Also note that if you lose your seed phrase, there is no way to get your own funds back. This is a huge hurdle for new users.

! [vvFxw94g95EIvo2NuFwxQX9g5mTtJo2EvxwLJO2y.png] (https://img.jinse.cn/7122937_watermarknone.png “7122937”)

Here are some things we can do to improve the user experience. We can:

• Create wallets without mnemonic phrases.

• Use a wallet that does not require storing ETH and paying gas fees with ETH.

• Use Social Recovery to retrieve your wallet.

• Bulk operations in one transaction.

! [dE8KCPMN0cVxJwYU2lm5yt5B9g3GLhSxilFQWvfW.png] (https://img.jinse.cn/7122938_watermarknone.png “7122938”)

2、Account abstract type

There are two types of accounts: external accounts (EOAs) and contract accounts. EOA is controlled by the private key, and the contract account is controlled by the contract code.

! [64lX5U5G6sNJZBjPvNiC827QJil9Zi8BpTNMeQ8Y.png] (https://img.jinse.cn/7122939_watermarknone.png “7122939”)

EOAs can initiate transactions to other EOA or contract accounts, which can then execute their code. Contract accounts can also send trades to other contract accounts, which can execute their own code.

3. The early days of Ethereum: transaction execution and verification**

When a transaction is sent to the network, it goes through two steps: verification and execution. While the execution of the transaction logic can be arbitrary, the validation part is fixed.

The verification part is done by a single fixed algorithm that EOA must use, that is, ECDSA signature verification. But why do we use a fixed method to verify the validity of transactions? What if ECDSA signature verification is no longer reliable in the future due to quantum computing?

If we leave the validation part open, then you can create a transaction with a very complex validation algorithm, then the miner/validator will have to spend a lot of resources to check if the transaction can be included in the block.

Now, note that miners are only paid for executing and including transactions, not for verification. So, if, after spending a lot of resources, miners find that they can’t add transactions, then they waste resources and don’t get paid anything for it. Therefore, this can be used to carry out DDoS attacks on the network. That’s why Ethereum started with a fixed verification algorithm.

4. The Early Days of Ethereum: The Multisig Adoption Problem**

A multisig wallet is a contract with a lot of owners with thresholds. If you want to send a transaction, you must get signatures from all owners before you can send the transaction.

This supports features such as social recovery, where you can have many friends to help you recover your wallet if you lose your private keys. From the early days of Ethereum, the value that multisig wallets can provide has been apparent. Therefore, the Ethereum development team at the time wanted Ethereum users to use multisig wallets. However, this did not happen.

Since the Ethereum development team envisaged users using multisig wallets, they did not add an automatic log for ETH transfers because they expected the multisig wallet to record every ETH transfer. Exchanges at the time had to parse ETH transfer transactions, not log them.

When someone tries to use a multisig wallet with ETH transfer logs, the exchange is unrecognizable because the exchange does not parse the logs. Therefore, this small assumption ultimately makes the adoption of multisig wallets more difficult.

EIP 86 and 1014: Account Abstraction First Step**

EIP-86 aims to introduce the smart contract wallet concept called “forwarding contracts”. These contracts are designed to only receive transactions from “entry point” addresses, which need to adhere to a specific format.

Now, to create a smart contract wallet, you need to have some ETH beforehand to pay gas fees. You can go to CEX and get some ETH, but because your smart contract wallet hasn’t been created yet, you can’t send ETH to the wallet yet.

If we can somehow know exactly the contract address before the smart contract is created, we can send ETH to that address and then create a smart contract wallet using ETH on the address.

That’s what EIP-1014 introduces. It introduces CREATE2 opcodes that allow you to determine the contract address before creating a smart contract. This is the first step towards account abstraction.

The original EIP-86 required significant changes to the protocol because the changes to the protocol required collaboration between node development teams and required extensive scrutiny, so it was never implemented. EIP-1014 was implemented in the Constantinople hard fork.

Community development: Gnosis Safe, Argent Wallet, Gas Station network**

In discussing the study of EIP, the community has already set out to develop its own solutions.

The most notable of these was the release of Gnosis Safe in 2018. Safe is a smart contract wallet that allows users to create multisig wallets and also allows users to batch multiple operations into a single transaction. It also allows users to pay gas fees using ERC20 tokens.

Another notable note is the release of the Argent wallet in 2019. Argent Smart Wallet supports users to create multisig wallets, and also allows users to pay gas fees using ERC20 tokens. It also allows users to use social recovery to retrieve their wallets.

The Gas Station Network (GSN), released in 2019, is a decentralized network that enables users to pay gas fees using ERC20 tokens. GSN can be used with any smart contract wallet.

EIP 2938 – A Giant Leap Forward

Starting in 2018, the Ethereum team turned its attention to the migration to PoS (proof-of-stake), which inadvertently led to less emphasis on EIP evaluation and implementation by research teams and node development teams.

This shift paved the way for EIP-2938 in 2020, two years after EIP-1014 was implemented.

The core idea behind the proposal is the introduction of smart contract wallets, which are designed to specifically receive specific types of transactions, which can be programmed to determine the gas cap of transactions and develop arbitrary verification methods.

The proposal introduces two new opcodes to handle transactions, and as highlighted earlier, including these core updates is a complex process.

In addition, there are open questions about how replay protection is implemented and how nodes can check the validity of these new types of transactions. While the proposal didn’t get much attention, it did pave the way for the next proposal (EIP-3074).

EIP-3074 – Highly Versatile Solution**

The proposal introduces two new opcodes: AUTH and AUTHCALL. The difference with this proposal is that it supports external accounts (EOAs) to delegate control to contracts. These opcodes are specified for “invoker” contracts, which have the potential to significantly enhance the functionality of any EOA.

The contract initiates a completely arbitrary transaction structure, making it easy to implement solutions such as multi-signature, batch and aid purchases, key recovery, and friendlier CeFi deposits. Due to its open nature, the proposal emerged as a highly versatile solution capable of meeting a wide range of use cases.

On the other hand, the neutral position of the proposal also poses some security challenges. Further discussion suggests a more opinionated AUTHCALL approach to mitigate the associated risks. This discussion led the researchers to arrive at a more optimized solution, resulting in EIP-4337.

EIP-4337 – Ethereum account abstraction without changing the consensus layer protocol**

! [HQ5SxXOpxJLs0tzXo1IgTdGxAe5XHPNAIJiDKUMM.png] (https://img.jinse.cn/7122940_watermarknone.png “7122940”)

EIP-4337 proposes a mechanism to bring account abstraction into Ethereum without changing the consensus layer protocol. Under this EIP, users interact with the Ethereum network differently; Instead of sending transactions, the user sends the UserOperation object to a separate memory pool. Sender is the account contract that initiates the user’s action. The bundler collects these operations and packages them into a transaction that triggers a handleOps call on the specified EntryPoint contract to perform the packaged operation. Paymaster is the entity that sponsors the transaction, and its details are included in UserOperation for fee processing.

Aggregator verifies aggregated signatures, improving security and efficiency. Bundler or client whitelisting supports entry points and Aggregator contracts, controls interactions and ensures proper execution of user actions on the Ethereum network, consistent with the goals of the account abstraction without changing the consensus layer.

Smart contract wallets deployed through this process autonomously manage random values and signature verification, providing extensive flexibility. This design helps create smart contract wallets that can handle multisig and packaged transactions, social recovery, and even pay fees using ERC20 tokens.

Some form of account abstraction like the one proposed in EIP-4337 could be implemented in Ethereum’s mid-term future, initially appearing in new L2 solutions and eventually entering Ethereum L1, thus expanding the scope of user interaction with Ethereum.

10、L2 - New Frontier

Updates to the core protocol are a significant hurdle when introducing any EIP related to account abstraction. Core developers have been busy with the ETH 2.0 roadmap, which has been a top priority for a long time.

But what about L2? Unlike Ethereum L1, which carries technical debt, recent L2 chains have an architecture that integrates account abstractions from the start.

For example, StarkNet is a ZK rollup that creates a unique account abstraction. In addition, Argent, known for its L1 smart contract wallet, launched ArgentX on StarkNet, embedding a custom account abstraction implementation that was heavily influenced by EIP-4337. These initiatives underscore the importance and applicability of account abstraction on the Ethereum blockchain.