Special thanks to Palla, James Zaki, and Emmanuel Batse for the review.
Disclaimer: if you’re familiar with Account Abstraction and are curious about how it works on Aztec, go right to the section “The most abstract Account Abstraction”.
Account Abstraction context
What is AA and why did the Ethereum community give it this name?
- Initially, all Ethereum accounts were Externally Owned Accounts (EOAs), controlled by the user’s private key (i.e. whoever has the private key owns the account).
- With the Ethereum evolution, it became clear that to make Ethereum accounts more flexible and unlock a number of use cases, we need to abstract some or all parts of the accounts. However, this is expected to happen without sacrificing decentralization or censorship resistance.
- Among the use cases to be unlocked are account recovery, gas sponsorship, multichain accounts, and support of signatures other than ECDSA, such as more efficient signatures (e.g. Schnorr, BLS), or more user-friendly ones (e.g. smartphone secure enclave).
- Among the account parts to be abstracted are authentication (“Who I am”), authorization (“What I am allowed to do”), replay protection, fee payment, and execution. But strictly speaking, if we abstract even one of them we already call it AA.
- Today, when one is talking about AA, they mean abstracted verification logic. It can be abstracted up to the protocol level or to the smart contract level. In particular, it usually implies that accounts are controlled by smart contracts (i.e. a piece of code) that describe the verification logic.
- By native AA, we mean that AA is implemented at the protocol level. As a rule, in this case, all the accounts on the network are smart contracts (i.e. no EOAs at all).
- By non-native AA, we mean that AA is implemented at the smart-contract level. In this case, there might be both EOAs and accounts controlled by smart contracts.
Note: the second option is sometimes also referred to as “contract wallets” or “smart accounts”.
The story of Account Abstraction
AA on Ethereum
The discussions around AA on Ethereum started around 2017. There were a number of EIPs and ERCs proposing different versions of AA (e.g. EIP-86, suggesting abstraction of transaction origin and signature, EIP-1014, and EIP-2938) that were explored and discussed but ultimately rejected, so we won’t cover them in this piece.
The first ERC affiliated with AA that made it to Ethereum mainnet was ERC-4337 (deployed on Mainnet in March 2023). It introduced AA without any modifications to the core protocol. It achieved this by replicating the functionality of the transactions mempool in a higher-level system. Instead of transactions, users send UserOperation objects to relayers, and these relayers package a set of these objects into a single standard transaction that is sent to Ethereum nodes.
Since then, the community has argued whether ERC-4337 is the Ethereum AA endgame or not. Right now, there is a dispute around EIP-3074 in the next Ethereum protocol upgrade. It suggests AUTH and AUTHCALL opcodes, which allow EOAs to delegate execution to smart contracts. However, one should note that the transaction validity still relies on EOAs’ ECDSA signature (i.e. ECDSA signature becomes enshrined).
This EIP is not new and some ecosystem players have discussed it being complementary to ERC-4337. The core question is what’s the more urgent problem for Ethereum to solve – censorship-resistance (against EIP-3074) or user experience (for EIP-3074)?
Account Abstraction on L2s
As Ethereum follows the rollup-centric roadmap, we expect most activity to happen on Ethereum L2s. As L2s technically don’t depend on Ethereum, they can implement AA on their own by introducing appropriate opcodes.
Some L2s have chosen a native AA “feature” as one of their core value propositions and implemented native AA (among those zkSync, StarkNet, and Aztec). In particular, this means that a transaction can be initiated directly by a smart contract (i.e. without any reliance on EOA).
As a comparison, in ERC-4337, AA is not native, as there is a step in the tx flow where an EOA account is engaged (as a Bundler).
As an alternative to enshrining AA in Ethereum, the Rollup Improvement Proposal (RIP) was proposed. RIP is a way to facilitate L2 standardization (not only around AA but around other L2 aspects as well). RIP-7560 is a native version of ERC-4337 for L2 chains currently under discussion. Check a series of RollCalls to learn more.
The most abstract Account Abstraction
While we talk about “arbitrary verification logic” describing the intuition behind AA, the logic is not really arbitrary. The verification logic (i.e. what can be checked as an authorization) is limited to make the verification time fast and bounded. That is the case for all chains where transaction validity is checked by the sequencer. Otherwise, it will cause UX downfall, whereas the main reason behind introducing AA is UX improvement.
On Aztec, there is no limitation on verification logic, as transaction validity check is executed client-side and a proof of validity is supplied to the sequencer. The sequencer only verifies the proof and this process is independent of the verification logic complexity.
This unlocks a whole universe of new use cases and optimization of existing ones. Whenever the dapp can benefit from moving expensive computations off-chain, Aztec AA will provide a unique chance for an optimization. That is to say, on traditional chains users pay for each executed opcode, hence more complex operations (e.g. alternative signature verification) are quite expensive. In the case of Aztec, it can be moved off-chain so that it becomes almost free. The user pays for the operations in terms of client-side prover time.
For example:
- Multisig contract with an arbitrary number of parties that can verify any number of signatures for free.
- Oracle contract with an arbitrary number of data providers that can verify any number of data entries for free.
However, one should note that if the verification logic depends on the public state and requires a public function call (e.g. checking the balance), this check will be executed by the sequencer and imply some limitations on the allowed complexity of verification logic. For those who prefer watching over reading, here is a talk, “Account Abstraction for a Private Network”, by Santiago Palladino (Palla).ConclusionAA is not a new topic, however, AA on private networks unlocks new capabilities for arbitrary verification logic, allowing for more complex logic as well as significant cost optimizations. Check documentation to dive into the details of Aztec’s AA. And if you are up to join Aztec’s building pioneers – express your interest in this form. Sources
- The website ERC-4337.
- An article, “Why 4337 and 3074 authors are disagreeing, and who got it right”.
- Notes on the Account Abstraction roadmap.
- A talk, “Account Abstraction for a Private Network” by Palla.
