Coming up soon in the Aztec3 roadmap is the design of an account abstraction mechanism, before fee management comes into the picture (1). I wanted to open to discussion whether we need or not to consider fees when designing AA.
I see two main reasons for getting fees into the design space along with AA: preventing DOS and supporting paymasters.
One of the main benefits of AA is implementing arbitrary logic for deciding when a call is “valid” (eg in Ethereum a call is only valid if the nonce is correct, the ECDSA signature is correct, etc). However, arbitrary validation logic means that validating whether a tx should be propagated is arbitrary expensive in terms of computation. Hence, most AA implementations limit what is doable in the validation step: EIP4337 limits what opcodes can be used or what storage can be accessed, zkSync follows a similar approach, and Starknet does not allow calls to external contracts.
A question would be whether this affects A3 transactions: it’d seem the cost of running the validation step is paid by the sender when constructing the private kernel circuit proof, so we should be good. We could have a problem if the validation step needs to be executed as a public function by the sequencer, but we could just restrict AA validation functions to be private. It’d be good to validate this to make sure we’re not missing anything here.
The other big consideration is paymasters, which means who actually pays for a user’s tx fee. This is another big UX win of AA, since it allows users to start interacting with the chain without having to acquire funds to pay for their gas, and having someone else cover that cost. To support this, eg EIP4337 defines an extension, and zkSync follows it with paymaster-specific methods in the account interface.
While it may not make sense to add paymaster support from the get go (eg Starknet has AA but have not implemented paymasters yet), it’d be good to make sure that our AA design doesn’t make it more difficult to introduce this extension later down the road.