What is Account Abstraction?

Every Ethereum account implements five functionalities:

• Authentication
• Authorization
• Replay protection
• Gas payment
• Execution

An EOA implements them in a hardcoded way:

• Authentication and authorization are bundled together: an immutable ECDSA key proves identity and grants full authority.
• Replay protection is a simple nonce - a monotonically increasing counter.
• Gas payment is done directly from the EOA’s ETH balance.
• Execution - a single call to a single destination.

Account abstraction means adding programmatic logic to these five functionalities:

• Authentication - any form of proving one’s identity.
• Authorization - any access policy.
• Replay protection - transaction ordering decoupled from replay protection.
• Gas payment - gas payment decoupled from the account itself.
• Execution - any execution logic.

Examples of account abstraction use cases

• Different signature schemes
  • secp256r1 (secure enclave, passkeys)
  • Schnorr
  • BLS
  • Post-quantum
  • ZK proofs (e.g. zkemail)
• Key rotation
  • Replace compromised keys
  • Deadman’s switch for inheritance (key becomes active if account is inactive for a year)
• Different access policies
  • Multisig
  • Role-based access
  • dapp-specific session keys
  • Social recovery
• Different replay protection schemes
  • Parallel transactions from different entities
  • Pre-signed future transactions to be sent by 3rd parties
  • Administrative channel
• Gas abstraction
  • Gas sponsorship by 3rd parties
  • Payment with assets other than ETH
  • Privacy: anonymous airdrop claims or withdrawal from ZK rollups or mixers
• Execution abstraction
  • Batching multiple calls to multiple destinations (e.g. approve+transferFrom)
  • Atomicity
  • dapp-specific UX improvements

ERC-4337 vs EIP-3074: False dichotomy

EIP-3074 aims to abstract Execution by supercharging the EOA with arbitrary execution logic through invokers. It has a unique property - extending the capabilities of an EOA without having to migrate assets to a new account. It does not need to address issues such as decentralized access because execution doesn’t affect this. The other four functionalities do, but they are outside the scope of EIP-3074.

ERC-4337 aims to abstract the entire account - all five functionalities. It’s a harder problem to solve if decentralization and censorship resistance are to be preserved. The focus of ERC-4337 is to mitigate DoS and griefing attack vectors enabled by abstracting the first four functionalities without resorting to centralized infrastructure. As an ERC it cannot extend the capabilities of an EOA, and requires migrating to a smart account.

The overlap between the two methods is minimal: only Execution abstraction.

In addition, each method aims to solve problems that the other doesn’t: EIP-3074 aims to serve existing EOAs and keep things as simple as possible. ERC-4337 aims to provide full Account Abstraction without sacrificing core properties of Ethereum, such as decentralization.

If one insists on comparing ERC-4337 to a previous proposal, the closest one is EIP-2938, not EIP-3074. EIP-2938 was a breakthrough in account abstraction, the first proposal to realize the difficulty of DoS mitigation in an AA mempool. ERC-4337 solves certain problems that EIP-2938 didn’t, but a full comparison is outside the scope of this document.

What can both ERC-4337 and EIP-3074 solve?

Both solve execution abstraction, and therefore enable the last category of the use cases above:

• Batching multiple calls to multiple destinations
• Atomicity
• dapp-specific UX improvements

What can EIP-3074 do, that ERC-4337 can’t?

• Add complex execution functionality to existing EOAs.
  • ERC-4337 can’t add functionality to EOAs because it’s an ERC.
• Simplicity and better gas efficiency when only execution-abstraction is needed.
  • Full account abstraction adds complexity that is not needed for execution abstraction.

What can ERC-4337 do, that EIP-3074 can’t?

• Support any EVM chain on day 1. No consensus changes.
  • EIP-3074 would have to be adopted by each chain through a consensus change.
• Permissionless innovation
  • Wallets will only allow whitelisted EIP-3074 invokers. ERC-4337 accounts can be built and used by anyone.
• Full account abstraction - all the above use cases, without sacrificing decentralization:
  • Different signature schemes.
    • EIP-3074 uses ECDSA. The EIP does mention a future path for moving to a different scheme, but as long as the EOA itself honors the ECDSA key, an invoker can’t prevent it from being used directly.
  • Key rotation.
    • With EIP-3074 the EOA still has an irrevocable key.
  • Different access policies
    • The ECDSA key can bypass the invoker and perform any operation in the account. No granular access control.
  • Different replay protection schemes
    • The account is still an EOA, and uses a 1-dimensional nonce.
  • Gas abstraction
    • The account pays for its own gas, with ETH.
    • A gas abstraction system could be built on top of EIP-3074, using a relay to send meta-transactions on behalf of the account. However, protecting such relays from DoS and griefing is a challenge, so they’ll likely become permissioned. Most of the ERC-4337 complexity is due to keeping those relayers (bundlers) permissionless.

Can EIP-3074 + EIP-5003 do what ERC-4337 does?

EIP-5003 complements EIP-3074 by letting the EOA revoke its ECDSA key and become a smart contract. As a contract it can abstract the rest of the account functionalities, e.g. replacing ECDSA with a different signature, rotate keys, apply access policies, etc. In that sense it is somewhat equivalent to proposals such as EIP-6913 and EIP-7377, but is superior to EIP-7377 because as an opcode it can use a gas abstraction system for the migration itself.

Once the EOA is converted to a smart contract, it can no longer transact directly and needs to be accessed through another EOA. This introduces the challenge that ERC-4337 is designed to solve. The user has two ways to transact with the account after migration:

1. Maintain another funded EOA to transact with the account, and sign each transaction twice. This negates the value of account abstraction and results in bad UX.
2. Use a relay that maintains a funded EOA, puts the transactions on chain and gets reimbursed by the account. Protecting such a relay against DoS and griefing is harder than it seems, so some projects run a permissioned relay. This results in loss of decentralization and censorship resistance.

The way to decentralize post-migration account access is to apply certain restrictions until the account pays the gas. This approach was taken by both EIP-2938 and ERC-4337. The @yoav/unified-erc-4337-mempool">ERC-4337 mempool offers a decentralized way to transact with the account.

TL;DR: No, it just highlights the need for ERC-4337.

Caveat: EOA migration considered harmful

It’s tempting for existing EOA users to migrate to a smart account in-place instead of transfering assets. However, it comes with certain vulnerability, some of which cannot be mitigated.

What could go wrong if the EOA key is compromised after it has been revoked?

1. The key remains valid on other chains (including future chains that do not even exist at the migration time). It can be used to claim the same account on other chains and transfer any assets sent to the account on these chains.
2. Off-chain systems such as the login process of dapp frontends check signatures. Many of them support EIP-1271 for smart contract signatures, but only try it if ecrecover fails. The key could be used to compromise the account on these systems.
3. It can be used on-chain (on the same chain where it has been revoked) to sign permit authorizations. If the account contains ERC-20 tokens that support permit, these tokens may get stolen using the revoked key.
4. Cross-chain bridges often check a signature during withdrawal. If the account sends funds to another chain through such a bridge, the revoked key may be used to withdraw the funds on the other side.

The user could burn the private key after migration and hope that no copies are left, but then the user also can’t claim the same address on other chains.

Therefore migration should be used as a last resort when there’s a strong reason to keep the old address. By default, new accounts are best deployed with CREATE2 rather than migrated from an EOA, so that they are not linked to an EOA key on other chains.

The community tends to overemphasize the importance of EOA migration because most current users have EOAs. The next billion users could start with a smart account and not have to migrate from an EOA. We, the current EOA users, are a tiny fraction of that. Migration may be important for a while, for current users to migrate. It’ll become a seldom-used flow when account abstraction is the norm.

Is there synergy between ERC-4337 and EIP-3074?

Yes, they could be @yoav/eip-3074-erc-4337-synergy">combined in interesting ways. If a chain adopts EIP-3074, projects that use ERC-4337 could use it to their benefit.

RIP-7560: A promising path for the future of account abstraction

Both EIP-3074 and ERC-4337 are steps to get some of the benefits of full native account abstraction. The former focuses on getting all the benefits of execution abstraction and the latter focuses on getting all the benefits of account abstraction on all EVM chains but in a non-native way that is less efficient.

A chain that wishes its users benefit from full native account abstraction could adopt RIP-7560. It uses the same account and mempool architecture as ERC-4337 but works natively at the protocol level.

RIP-7560 doesn’t have to be adopted from day 1, and existing accounts will be able to migrate to it on chains that choose to adopt it any time in the future:

• ERC-4337 accounts will be able to migrate to RIP-7560 without changing their architecture, by changing their implementation to trust the special EntryPoint address defined in RIP-7560. An account can be both ERC-4337 and RIP-7560 compatible with little effort, so no migration is even necessary.
• EOA may be able to migrate directly to RIP-7560 without going through ERC-4337 or EIP-3074. RIP-7560 already supports gas abstraction for EOAs. A future RIP could let the EOA set its code, whether using an opcode like SETCODE (EIP-6913) or AUTHUSURP (EIP-5003), or by adding a TransactionType4 subtype similar to EIP-7377. This opcode/subtype could be used by a migration contract which is called in Type-4 (RIP-7560) transaction. However, EOA migration is @yoav/erc-4337-vs-eip-3074-false-dichotomy#Caveat:-EOA-migration-considered-harmful">discouraged.

RIP-7560 needs your feedback

We are collecting feedback on RIP-7560 before proposing to enshrine it. If you’re interested in native account abstraction, please review the PR or join the discussion.

Disclaimer：

1. This article is reprinted from [@yoav]. All copyrights belong to the original author [@yoav]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.