# AA Design Breakout Notes ### Whiteboard photo  **Session Overview** This breakout session focused on establishing a shared understanding of the goals and constraints for Native Account Abstraction (AA) on Ethereum. The facilitators deliberately separated the discussion from specific proposals (such as EIP-7702 or Frame Transactions) in order to define the problem space first, ensuring that future proposals can be evaluated against a common set of requirements and limitations. **Core Goals for Account Abstraction** The participants established the following essential features and properties that a native AA solution must support: - **Alternative Signature Schemes:** Support for any signature type - including multi-sig, R1, and post-quantum signatures - not just the standard ECDSA. This encompasses arbitrary validation logic. - **Signature Aggregation:** The ability to aggregate signatures, particularly post-quantum ones, to reduce block size and computational load. - **Call Batching:** Atomic execution of multiple top-level calls within a single transaction at the protocol level, rather than relying solely on application-layer batching. - **Account Recovery & Key Management:** Mechanisms for changing keys or recovering accounts without relying solely on a single seed phrase, and without losing the account address. - **Post-Transaction Assertions:** A security feature allowing users to define the intended outcome of a transaction (e.g., "only transfer X tokens"). If the assertion fails, the transaction reverts. This is designed to protect users against phishing, drainer contracts, and malicious contract interactions. - **Gas Sponsorship:** Allowing a third party to pay transaction fees on behalf of a user. - **Flexible (2D) Nonces:** Moving away from strictly sequential nonces to support use cases like privacy pool withdrawals, where a nullifier acts as a nonce and sequential ordering is impractical. - **Keystore Wallets:** Cross-chain account management where L1 defines the keys for L2s, so an account created on L1 is automatically available on L2s without repeating setup operations on every chain. - **Default Accounts:** Upgrading Externally Owned Accounts (EOAs) to behave as minimal smart accounts with AA features without requiring users to deploy code. This addresses UX and adoption concerns raised by wallets like Rabby regarding EIP-7702. **Key Constraints & Design Philosophy** A significant portion of the discussion focused on the hard constraints that any AA solution must respect. There was an emphasis on the disconnect between the desired feature set and the realities of protocol-level limitations: - **No Relayers:** A core philosophical and technical stance - users must be able to submit transactions directly to the public mempool without relying on a centralized relayer. This is considered essential for censorship resistance, even if relayers are common in practice. - **Public Mempool Compatibility:** The solution must work safely within public mempool rules and support inclusion lists (e.g., FOCIL) to prevent centralization of transaction inclusion. Arbitrary validation logic that is cheap to submit but expensive to verify creates denial-of-service vectors. - **Statelessness Compatibility:** The design must be compatible with future stateless client architectures. This restricts how much state a transaction's validation phase can access - for example, limiting access to ERC-20 token balances. A concept called "Validation Only Partial State" (VOPS) was discussed, where nodes would only keep the top N storage slots of an account for validation purposes. - **L2 Compatibility & DoS Resistance:** L2s (such as Arbitrum) face a specific threat where a malicious sequencer can flood the network with invalid transactions that are computationally expensive to verify but cheap to post as data, potentially crashing nodes. Any AA solution must prevent this class of attack. The Frame Transaction approach of separating the validation phase from the execution phase was discussed as one way to bound validation costs and allow nodes to identify and drop invalid transactions more efficiently. #### Major Debates & Discussion Points **Arbitrary Validation vs. Pre-compiles** There was significant debate over whether to support arbitrary EVM logic for transaction validation (maximizing flexibility for custom logic such as daily spend limits) or to restrict validation to a fixed list of supported signature schemes and pre-compiles (improving efficiency and safety). Proponents of the Frame Transaction approach argued that arbitrary validation is necessary but should be isolated - for example, preventing state writes during the validation phase - to mitigate DoS risks. Critics pointed to the complexity and attack surface this introduces. **ERC-20 Gas Sponsorship** While highly desired by wallets, supporting gas payment in ERC-20 tokens natively within the mempool requires state access (checking token balances), which conflicts with statelessness and mempool safety requirements. The group leaned strongly toward supporting only ETH-denominated gas sponsorship natively, leaving ERC-20 sponsorship to relayers or application-layer solutions. **Privacy Pools** Privacy pools served as a key example for the need for flexible nonces and were acknowledged as a high-priority use case. However, supporting privacy pool withdrawals in a stateless mempool is technically challenging because the pool contract effectively acts as the sender, requiring access to its full state (nullifiers, roots). Suggestions included whitelisting specific contracts, submitting witness proofs, or creating a "canonical privacy pool handler" - but no final solution was reached. This remains an open design challenge. **Post-Quantum Signatures** There was agreement that hash-based post-quantum signature schemes are the viable near-term path. Lattice-based signatures are currently too expensive and complex for ZK-EVMs/ZK-provers to prove efficiently and carry prohibitive gas costs. Only hash-based schemes will be targeted initially. **L2 DoS Mitigation** The specific L2 concern - that arbitrary validation logic enables block-stuffing attacks with computationally heavy but invalid transactions - was discussed at length. The Frame Transaction proposal's approach of separating validation from execution, and bounding the gas cost of the validation phase relative to the transaction's data size, was proposed as a mitigation strategy. #### Rough Consensus & Decisions - **No ERC-20 Gas Sponsorship Initially:** The core protocol will support only ETH gas sponsorship natively to maintain mempool safety and statelessness. ERC-20 sponsorship will rely on relayers or wallet-level solutions. - **Hash-Based Post-Quantum Only:** Only hash-based post-quantum signature schemes will be supported initially; lattice-based schemes are deferred pending further pre-compile research. - **Privacy Pools Acknowledged as High Priority:** Recognized as an important use case, but technically challenging within the constraints. No final design was settled. - **Arbitrary Validation Must Be Bounded:** While arbitrary validation logic is a goal, it must be constrained (e.g., via a validation gas limit) to mitigate DoS risks on L2s and in the mempool. **Actionable Items** - **Define Mempool Policies:** Develop specific policies for what types of transactions and validation logic are permitted in the public mempool (e.g., gas limits on validation). - **Define a Canonical Paymaster:** Further explore and specify a "canonical paymaster" contract to enable safe ETH gas sponsorship within public mempool rules. - **Investigate VOPS:** Explore "Validation Only Partial State" as a mechanism for stateless nodes to validate AA transactions without holding full state. - **Address L2 DoS Risks:** Develop specific strategies to prevent DoS attacks on L2s, potentially by bounding validation gas relative to transaction data size, and continue analyzing how the Frame Transaction separation of validation and execution mitigates these risks. - **Explore Privacy Pool Compatibility:** Investigate a generic canonical handler or witness mechanism for privacy pools to function within stateless mempool constraints without hardcoding specific contracts into client code. - **Scope Gas Abstraction:** Formally decide on the initial scope for gas sponsorship - ETH-only in the public mempool - and document the path for future ERC-20 support. - **Continue Post-Quantum Pre-compile Research:** Further investigate pre-compiles needed for lattice-based post-quantum schemes for potential future inclusion.