# Notes on the Account Abstraction roadmap *Special thanks to Vitalik and the AA team for feedback and review.* [toc] ## The past: where we started Three years ago (2021) Vitalik [proposed](https://notes.ethereum.org/@vbuterin/alt_abstraction) a new account-abstraction model and we started brainstorming what later became [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337). We had set on a [long journey](https://notes.ethereum.org/@vbuterin/account_abstraction_roadmap), with the goal of achieving full AA (abstracting [all](https://notes.ethereum.org/@yoav/erc-4337-vs-eip-3074-false-dichotomy#What-is-Account-Abstraction) aspects of the [account](https://erc4337.mirror.xyz/vYwclVbG6CR1o8DOCWDj8cFVfFSJ07FhWTDgQ5NQROY): authentication, authorization, replay protection, gas payment, execution) without sacrificing decentralization and censorship resistance. The rabbit hole turned out deeper than we anticipated. Censorship resistance required a permissionless mempool, but full AA opens up a lot of DoS vectors that make this a [challenge](https://notes.ethereum.org/@yoav/unified-erc-4337-mempool). We quickly realized that we need to separate validation from execution, and then apply certain restrictions during validation. EOA does that naturally and has very strict validation rules (exactly one ECDSA signature check of an unrevocable key, one nonce check, one balance check, no external dependencies). We wanted AA to enable as many use cases as possible while remaining DoS resistant and without resorting to permissioned methods such as whitelisting. The process started with figuring out a minimal set of validation rules that prevent cheap DoS. We got there but it was quite restrictive. Then came the harder part - figuring out what exceptions can be made safely, enabling more use cases without introducing DoS vectors. This ultimately resulted in [ERC-7562](https://eips.ethereum.org/EIPS/eip-7562). The rules have been extracted from ERC-4337 in order to enable AA use cases that don't use the mempool (e.g. intents) and to support native forms of AA that do not use ERC-4337. ## The present: where we are now ERC-4337 launched on all major EVM networks in March 2023 and has been gaining [traction](https://www.bundlebear.com/overview/all) among users and developers. At the time of this writing 4.1M accounts have been deployed and 18.2M UserOps have been sent, and there's a thriving ecosystem of [projects](https://github.com/4337Mafia/awesome-account-abstraction) built on ERC-4337.. The accumulated data revealed some insights on how users use AA. In particular, the vast majority of the UserOps uses paymasters, indicating that our design choice of making gas abstraction a core feature has been the right one. We recently shipped v0.7 which we hope to be the last breaking change. The mempool itself (the p2p network) has [launched](https://twitter.com/etherspot/status/1768717020047020471) on testnet with several bundler implementations participating, but is not live on mainnet yet. Being a multi-client architecture (like Ethereum itself), it requires a lot of interop and stress testing. Bundlers on mainnets are currently operating as private mempools but that will change soon, as the mempool goes live. Over the past couple of years we discovered that there is demand for an enshrined protocol-level version of ERC-4337. Some L2 networks (e.g. [zksync's native AA](https://docs.zksync.io/build/developer-reference/account-abstraction.html#design)) implemented their own versions of it. This caused inevitable wallet fragmentation, where some wallets only work on certain networks. We realized that certain things need to be standardized across L2 chains - beyond just AA, and started the RIP (Rollup Improvement Proposals, aka RollCall) process to facilitate this. Since then we've been working on [RIP-7560](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7560.md), a native version of ERC-4337 for L2 chains. ## The future: where we are heading ### Native AA - a modular roadmap Our current focus is a set of RIPs to help L2 chains migrate to native AA. RIP-7560 started as a monolithic RIP but it won't stay that way. We've been [stripping](https://github.com/eth-infinitism/RIPs/pull/4/files) it down to its bare minimum usable form, moving parts of it to separate optional RIPs. The PRs are still early [drafts](https://github.com/eth-infinitism/RIPs/pulls) but will be published as RIPs in the near future. Some things that have been moved out: - [All validations before any execution](https://github.com/eth-infinitism/RIPs/pull/3/files) - not needed on single-sequencer rollups but highly recommended on decentralized chains to ensure DoS resistance, and mandatory if aggregation is used. - [2D nonces](https://github.com/eth-infinitism/RIPs/pull/5/files) - not mandatory but enables multi-tenant accounts, parallelization and other use cases. - [Aggregation](https://github.com/eth-infinitism/RIPs/pull/2/files) - enables signature aggregation as well as advanced use cases such as transaction atomicity for intent solvers. - [All EOA related extensions](https://github.com/eth-infinitism/RIPs/pull/1/files) - incrementally adding certain AA capabilities to EOA, and ultimately migrating EOA to AA. - [Getting rid of the ABI](https://github.com/eth-infinitism/RIPs/pull/6/files) - becomes possible when EOF is included. L1 core devs, L2 devs, and the entire community are invited to collaborate and provide feedback. ### What about L1 The roadmap has been focused on L2 but there is value in [enshrining](https://vitalik.eth.limo/general/2023/09/30/enshrinement.html) AA on Ethereum L1 as well. We expect that this will take longer but it shouldn't delay L2 adoption. RIP-7560 and the extracted RIPs are compatible with the ERC-4337 account model, so it'll be possible to deploy the same account on different chains, where some work natively and some use ERC-4337. It is likely that Ethereum L1 will keep using ERC-4337 much longer while L2 chains gradually move to RIP-7560, but users and projects will work the same on both. ERC-4337 and RIP-7560 may live alongside each other for years until the migration is completed. One trade off that RIP-7560 had to make, which may not fit L1, is the solidity ABI dependency. Ideally, EIPs should avoid depending on solidity, and this has been mostly the case on L1 (with the exception of the [deposit contract](https://etherscan.io/address/0x00000000219ab540356cbb839cbe05303d7705fa#code) which introduced a solidity dependency to stake the consensus layer). L2 chains don't try to avoid such dependency, and most of them use [precompiles](https://arbiscan.io/address/0x0000000000000000000000000000000000000064#code)/[predeploys](https://optimistic.etherscan.io/address/0x4200000000000000000000000000000000000015#code) with an ABI. A cleaner way to implement RIP-7560 would be to use EOF, and leave ABIs to a higher abstraction layer (e.g. solidity). However, as we've seen above some L2 chains are not going to wait for L1 to include EOF, and wish to enshrine AA sooner. Therefore RIP-7560 currently makes use of an ABI. L1 is less likely to make the same trade off, and has a longer time horizon for introducing features like native AA. For L1 there is the [EOF version of RIP-7560](https://github.com/ethereum/EIPs/pull/8516/files) which will make a clean separation between the protocol side and the user-facing side. It's still work in progress but feedback from EOF devs would be appreciated. ### How can we assist EOAs in the meantime There has been demand for adding certain AA capabilities to EOA. While the goal should be full AA rather than [further enshrining EOA](https://ethereum-magicians.org/t/we-should-be-moving-beyond-eoas-not-enshrining-them-even-further-eip-3074-related/6538), the need for features like batching and gas abstraction has been obvious and well demonstrated by recent debates around EIP-3074. The roadmap does not ignore this demand, but these features should be added as part of a strategy that leads us to AA rather than making ad-hoc improvements to EOA and introducing future technical debt. Many AA capabilities become available to EOAs using the same TransactionType4 used by the other RIPs above, via the [EOA extensions RIP](https://github.com/eth-infinitism/RIPs/pull/1/files) that has been extracted from RIP-7560. It has some advantages over the immediate adoption of EIP-3074: - Consistent with the native AA roadmap. Wallets won't need to support two standards. - Enables EOAs to use the existing paymasters. The paymaster doesn't care that the sender is an EOA. - Requires less trust than EIP-3074 for most common use cases. Gas abstraction and batching don't require entrusting a contract with full account access. Therefore no whitelisting required. - Enables EOA migration to AA using paymasters (as opposed to [EIP-7377](https://eips.ethereum.org/EIPS/eip-7377)). - Enables signature aggregation for EOAs (combined with the [aggregation RIP](https://github.com/eth-infinitism/RIPs/pull/2/files)), which could save significant amount of network fees for rollups. - No need for relays or specially-crafted 4337 invokers. EOAs will use the AA mempool. - Not introducing further technical debt that will slow us down when we move to quantum-resistant signatures. As an intermediate step, this RIP could also be adopted without RIP-7560 so it doesn't introduce native AA but uses the same transaction type so it is forward-compatible with it. This would include EOAs in the AA roadmap rather than start a parallel improvement path.