AA Goals and Constraints

# AA Goals and Constraints ## Goals ### Required - **Alternative Signature Schemes** - Other signature schemes are supported unconditionally and in any permutation - Generally will require cyptographic precompiles anyways - **Authorization and Gas Payment Separation** - This directly allows many types of paymastering and transaction sponsorship - It, in combination with mempool policies, allow relayerless sponsorship - **Arbitrary Validation** - An invalid transaction should not cost the user gas - If constraints are validated after transaction decides to pay, user may be forced to pay for a reverting transaction - **Signature Aggregation Compatibility** - One insight is that signature aggregation schemes generally have the same interface. They take the public key, message, and signature and then output a witness - Our AA solution does not need to immediately support signature aggregation but should support the above interface and allow for the signature to be fully removed in the future - **Batching** - Must also have correct handling for more complex interactions such as atomic calls - Wallets have signaled clearly that they prefer the protocol to provide batching as a first class primitive - **Key Rotation** - This officially breaks the cryptographic link between an address and keys associated with it - An important subgoal is supporting arbitrary account recovery mechanisms - **Unified Account Address** - With the cryptographic link between owner key and account broken, need a new mechanism to unify the account across many chains - **Assertions** - While somewhat of a sidequest, asserting the result of a transaction was identified as the most important change that can be made for account security - Providing a first-class experience will ensure wallets broadly incorporate support ### Stretch - **Default Accounts** - If account populations look anything similar to today, most users will use EOA/default accounts - Having a default "smart" account gives the protocol a mechanism to export features to its largest class of users - **2D / Flex Nonce** - There are many occasions where a user wants to accomplish two unrelated tasks, but sequential nonces enforce a certain ordering for unrelated operations - Some multi-tenant AA use cases, such as relayerless privacy pools, require support for parallel nonces - **ERC-20 Token Sponsorship w/o Bundler** - Paying for gas with tokens is a major use case of AA - Bundlers add a point of centralization that we prefer to remove, however, it is difficult to safely convert arbitrary ERC-20 tokens to ether - Other protocols solve this by having a canonical AMM - Supporting token sponsoship also substantially increases the state required to participate in the mempool, which can affect future stateless proposals - **Privacy Pool w/o Relayer** - Relayers can defeat the purpose of using a privacy pool, so supporting relayerless privacy pools is an important goal - There are two main changes needed to nicely support the privacy pool - 1) 2D nonce can allow the nullifier to be the replay protection mechanism and avoid contention among multiple users - 2) Choosing a few canonical privacy pools to retain state of in VOPS world will allow privacy pools to be used by public mempool - Without 2) it could be possible to provide a witness for the nullifier and still support in public mempool - **Keystore Wallet** - The cryptographic relationship of EOAs meant there was no account configuration that needed to be shared across chains - With AA, it's no possible for a chain to have a stale account configuration. The keystore is an idea for efficiently representing and propagating configuration changes to all EVM chains. - **Memo** - Exchanges and bridge protocols could benefit from an user-definable identifier that is separate from the calldata of the transaction ## Constraints - **No Relays** - Core features of the chain must be usable without going through an intermediary or relayer - For example, we believe privacy pools to be more of a core feature than paying for gas with ERC-20 - **Don't break L2** - AA must not put undue and unsolvable complexity onto L2s - **Passes Walkaway Test** - AA and the core features of the protocol must not require on going work and maintence - **Works with Future Plans** - This includes FOCIL, stateless, and zkEVM - **Everything Works with Public Mempool and FOCIL** - The public mempool is a core public good offered by the protocol today and embodies many of our core values, such as decentralization and censorship resistance - **Validation Compute Must be Bounded** - Not only must it be bounded, but the bound must be easily identifiable by the protocol to reason about it and abide by it