# Account Abstraction Status ## Goals of AA * **Gas sponsorship**: Where a different account (which can be a smart contract) pays for the fees of a transaction initiated by a different account * **Transaction batching**: Easy one-to-many transactions that does a bunch of DeFi things at once * **Signer-Account split**: Separate the funds from the private key to make key rotation/revocation easier * **Custom validation logic**: Natively support multisigs, threshold signatures, different signature schemes, etc. but also things like "a single signature is enough to transfer under $x per day, but for larger amounts a 2-of-2 signature is needed", or force a delay for large transfers and have them be cancellable by an alternate private key * **Signature aggregation**: Allowing the bundling of many transactions that can be verified by a single signature (e.g. with BLS signatures) Consensus is that we want all of these (and more), but it would be nice to have the first two on the short term. There are still questions/doubts: * Should the core protocol natively support these things? Smart contracts can achieve these goals (e.g. Gnosis Safe, 4337) without changing L1 and introducing complexity and extra risks * Can we solve *some* of these goals with smaller EIPs in the short term without backing ourselves into a corner on the long run if these incremental changes turn out to be incompatible with some as-of-yet unknown AA standard we'd love to enshrine * *Should we* solve some of these goals specifically, or aim to keep the core protocol as general purpose as possible? * Should L1 pave the way and unify a specific AA standard that L2s follow, or should L2s take the lead with the innovation and adoption, and we eventually enshrine the best design to L1? * Can this be done while respecting core tenets of decentralization, censorship resistance and permissionlessness? i.e. if some *paymaster* or *bundler* entities are involved, we don't want them to naturally converge towards untamed centralization with no fallbacks for users * How complicated does this make the life of smart contract developers? Can EOAs become smart wallets without breaking workflows of existing contracts? ## Short term EOA improvements / steps toward AA for Pectra * EIP-3074 is a good candidate for inclusion as a * ✅ Improves user experience (namely around sponsorship and batching) * ✅ Simple to implement * ❌ Sponsorship/batching would rely on centralized elements * with a [few tweaks](https://hackmd.io/ChB8t4lvR6q13suW0e_5RQ?view), it's be possible to leverage 4337-related infrastructure around relayer decentralization * Compatible with the 4337 endgame, [see here](https://notes.ethereum.org/@yoav/eip-3074-erc-4337-synergy) * EIP-5806 enables batch calls directly from an EOA * The transaction type format could be enhanced with the mechanism from [EIP7949](https://github.com/ethereum/EIPs/pull/7949) (separate *sender* from *payer*) to enable gas sponsorship * ✅ Simple to reason about from a security perspective * ❌ Extra transaction type to maintain, concerns around being "the next access list" * Allow EOA->AA wallet migration via [EIP-5003 (AUTHUSURP)](https://eips.ethereum.org/EIPS/eip-5003) or [EIP-7377 (one-time migration)](https://eips.ethereum.org/EIPS/eip-7377) * ✅ Cheap and fast compared to having to move every asset one by one * ✅ "Hands off" approach, no single standard imposed on users * ❌ A migrated EOA's original private key can still [cause trouble in some cases](https://notes.ethereum.org/@yoav/erc-4337-vs-eip-3074-false-dichotomy#Caveat:-EOA-migration-considered-harmful) * Concerns around users not caring to convert, but potentially mitigated by an eventual [mandatory conversion](https://notes.ethereum.org/@vbuterin/account_abstraction_roadmap#Mandatory-conversion) * Look into banning `ORIGIN` opcode, i.e. remap `tx.origin` to `msg.sender` – requires analysis to see what would break from doing that ## Medium/long term options * Continued 4337 implementation/adoption, with push for [RIP-7560](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7560.md) * ✅ All app-layer, no risk to core protocol * ✅ [Provides a decentralized fee market for user operations](https://twitter.com/VitalikButerin/status/1576199517434949634) * ❌ 4337 expensive to deploy/use on L1 * Enshrine 4337/7560 at Layer 1 * ✅ Essentially endgame AA utopia * ❌ Pretty inefficient with calldata * ❌ Lose ability to do bundle compression (unless it's also enshrined) * ❌ Complexity/risk # Links * [Vitalik Buterin – The road to account abstraction](https://notes.ethereum.org/@vbuterin/account_abstraction_roadmap) * [Alex Forshtat – Native Account Abstraction Roadmap](https://hackmd.io/@alexforshtat/native-account-abstraction-roadmap) * [Yoav – Can EIP-3074 and ERC-4337 be used together?](https://notes.ethereum.org/@yoav/eip-3074-erc-4337-synergy) * [Yoav – ERC-4337 vs EIP-3074: False dichotomy ](https://notes.ethereum.org/@yoav/erc-4337-vs-eip-3074-false-dichotomy) * [Future EOA/AA Breakout Room notes](https://notes.ethereum.org/QT9e9r6NRdSOjWRBzA3JLA?view) * Relevant proposals * [**ERC-4337** - Account Abstraction Using Alt Mempool](https://eips.ethereum.org/EIPS/eip-4337) * [**ERC-7562** - Account Abstraction Validation Scope Rules](https://eips.ethereum.org/EIPS/eip-7562) * [**RIP-7560** - Native Account Abstraction](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7560.md) * [**EIP-3074** - AUTH and AUTHCALL opcodes](https://eips.ethereum.org/EIPS/eip-3074) * [**EIP-5003** - Insert Code into EOAs with AUTHUSURP](https://eips.ethereum.org/EIPS/eip-5003) * [**EIP-5806** - Delegate transaction](https://eips.ethereum.org/EIPS/eip-5806) * [**EIP-2938** - Account Abstraction](https://eips.ethereum.org/EIPS/eip-2938) * [**EIP-7377** - Migration Transaction](https://eips.ethereum.org/EIPS/eip-7377) * [**EIP-7553** - Separated Payer Transaction](https://github.com/ethereum/EIPs/pull/7949) * [**ERC-7562** – Account Abstraction Validation Scope Rules](https://eips.ethereum.org/EIPS/eip-7562)