# Account Abstraction: challenges and solutions [toc] ## Motivation This document is about a discussion between the Ethereum team and AA wallet teams that were initiated by Vitalik. The AA team highlighted several issues they were currently facing. I have collected the topics and content of our discussions for internal review and learning (especially for zkEVM rollup-related parts). ## Critical Issues ### Multichain implementation The design goal of multichain AA wallet is to achieve address consistency and state (e.g. signing key, settings) consistency across multichain. #### 1. Address consistency across multichain This means that there is an AA account with the same address on different chains. - pros: the same as EOA - cons: hard to maintain. create2 needs to keep the same initial parameters (sign keys, guardians, salt). need to deploy the initial version contract even if latest version is 100.0 - if not: lost money, a user mistakenly sends funds to a new chain but fails to deploy the same account on that chain; some bridges assume using the same address for the cross-chain asset transfer. #### 2. State (e.g. signing key, settings) consistency across multichain The one state across all chains enables a single set of guardians and recovery mechanisms to efficiently manage and secure the associated accounts on every chain. - pros: good UX. Users just need to set guardians/recover on one chain. - cons: high gas cost. need to rely on something like a bridge? - if not: users manage multiple settings on different chain(need to set guardians on different chain);if lost wallet, user need to recover account one by one. #### 3. How to implement? As with the withdrawal & engine API and the corss-chain bridge, there are fundamentally two models. - Push Model ![](https://hackmd.io/_uploads/SyjlcrH73.png) - Pull Model ![](https://hackmd.io/_uploads/HyTNcrSQn.png) ![](https://hackmd.io/_uploads/HyT_9HSmn.png) #### 4. Conclusions - More [details](https://www.figma.com/file/clj4VsEhGyOX49Zxw9C502/Untitled?node-id=0-1), [discussions](https://forum.safe.global/t/how-can-a-safe-hold-asset-on-multiple-chains/2242) - **Related to Scroll** - L1 is unlikely to be modified much, and a more promising option is to implement multi-chain through L2's solution (the AA team is researching this - One idea is to store a unified metadata in L1 and access this data separately in different rollups. This requires the ability to access and **track the L1 state at L2** - EIP4377-based AA wallet must first solve the problem of implementing multi-chain on different EVMs (L1, AR, OP, Scroll), and after that, it must solve the problem of multi-chain on EVMs and non-EVMs with each other (Scroll, StarkWare, etc.) - An enlightening point is the multi-chain solution of ENS (ENS is deployed to a different chain and still uses the same identity system). For example, [this video](https://www.youtube.com/watch?v=mDNyxWSgFRQ) ### Wallet Privacy: Recover without revealing guardians #### 1. How it Works? Hide wallet guardians by setting guardian hash in the contract ``` setGuardian(address _guardianHash) where _guardianHash = hash(salt, guardianAddress1, guardianAddress2, …) ``` When recovery, the wallet validates the guardian list and guardians’ signature. So users can see guardians by their signatures, they will be **leaked** #### 2. Solution A: use ERC-1271 This EIP propose a standard way for contracts to verify whether a signature on a behalf of a given contract is valid (just like EOA account) more [details](https://eips.ethereum.org/EIPS/eip-1271), [more explanation](https://www.youtube.com/watch?v=p_UG1x53TWc) #### 3. Solution B: use stealth addresses more [details](https://vitalik.ca/general/2023/01/20/stealth.html) #### 4. Solution C: zk-snark everything Do a layer of zk-snark circuits for the `recovery` process to ensure that signatures are not leaked (vitalik's idea) - pros: simple, can do to protect privacy, and don't leak signatures. - cons: implementation complexity and audit difficulty for AA wallets ### Institution Guardian / Public Guardians Not every AA user may be able to find friends as their guardians at the beginning. What if the user has no friends? Is there a way to use AA wallet? #### 1. AA Wallet offers public guardians Idea from Soul Wallet: offer a (optional) public guardian that verifies the user’s email/phone number and will sign the recovery record. After a period of time, or if the asset exceeds the threshold, we will notify users to add their own guardian How it works? - Use multisig wallets as guardians, rate-limit the number of signatures in contract - Publish proof of receiving users' email requests for recovery (core) - In the long term, support other institutions as guardians #### 2. Guardian institution Similar to the mechanisms of PoS and staking pool, some organizations offer public guardianship services The two problems that need to be solved are how to prevent Sybil attacks (i.e., [proof of humanity](https://proofofhumanity.id/)) and how to provide economic incentives and penalties (e.g., by [using staking](https://en.wikipedia.org/wiki/Proof_of_stake)) My idea👇 - Sybil resistance: **Proof of Humanity** or **Proof of Stake** - Economic incentives and penalties: **Stake some token** (can be Scroll, AA, ETH, etc.), and have corresponding incentive and slashing mechanism ## Conclusions This discussion explores the technical challenges and potential solutions faced during the development of an EIP-4337-based AA wallet. Since EIP-4337 is relatively close to our smart contract wallet solution, I have distilled the key points from the discussion to facilitate internal research and learning. A particularly useful point for Scroll is the idea of cross-chain integration through L2 Merkle trees/Merkle proofs and L2 State. This concept, together with zk-snark is akin to the architecture employed by numerous cross-rollup bridge solutions (e.g., [slush](https://hackmd.io/@kalmanlajko/rkgg9GLG5), [wisp](https://ethresear.ch/t/wisp-zk-based-cross-rollup-communication-protocol/15059)).