Thread by @keoneHD

Account Abstraction is confusing because there are a lot of different flavors and a lot of stated benefits.

But the simplest description is: "we want EOAs to have smart contracts"

If we add smart contracts to EOAs, we can (for example) support alternate signature schemes, because the smart contract can:
- keep another public key from another schema (e.g. Passkey) in storage
- verify messages signed by the corresponding Passkey privateKey before executing arbitrary calls via multiCall

Adding smart contracts to EOAs will be a big change and could be chaotic. If it is done naively, accounts will be in a variety of states, and upstream users will have weaker assumptions.

The various flavors of AA (EIP-4337, EIP-3074, EIP-7702) all stem from different approaches to dipping Ethereum's toes in the water with respect to adding smart contracts to EOAs.

EIP-4337 accomplishes "add smart contracts to EOAs" by just telling people "just use a smart contract wallet for now"

EIP-3074 "adds smart contracts to EOAs" by adding two opcodes, AUTH and AUTHCALL, which couple an EOA to a separate smart contract account
- an EOA calls AUTH to attest that a separate contract (the "invoker account") has permission to spend the EOA's assets / call functions on the EOA's behalf
- the invoker acount can use AUTHCALL to make a CALL to a contract as if the EOA were the caller

EIP-7702 "adds smart contracts to EOAs" by allowing EOAs to point to a separate contract account which contains code.
- after this is done, the EOA is "delegated" to that other contract from a code perspective
- people (or the EOA itself) can call the EOA as a contract, and the code from the delegated address will be run as if it were deployed at the EOA

EIP-7702 is elegant in the sense that it doesn't require additional opcodes, and it doesn't open up the EVM to the full craziness of arbitrary bytecode directly on each EOA.

The main protocol modification is adding a new transaction type by which the EOA owner (privateKey holder) signs a delegation to an external contract for its code.

Once that is done, the EOA owner also needs to set up the new authorization method (assuming there is one). For example if another signature scheme like Passkey is going to be used for authentication, the EOA owner needs to upload their Passkey public key to storage along with a ECDSA signature attesting to that newPublicKey.

Once this is done, UserOps can be submitted to the EOA (treating it like a smart contract), signing using the Passkey private key.