# Primer on AA and its security implications silur@web3fc --- ## [silur@web3fc]$ whoami - Forbes 30/30 Independent consultant and developer - Quantum/Cryptography Researcher @ Wigner's institute - Ethical hacker - Co-founder @ Defaince.ai & QANplatform.com & Altcoinist.com - Co-organizer of CCTF --- ## Agenda - Account types on ETH and their shortcomings - Prior work before AA - Choosing the middle-ground - Lifecycle breakdown - Current state of AA - Usecases - Security issues solved - Security issues to remain - New security issues introduced ---  <small>source: https://takenobu-hs.github.io/</small> --- ### Contract accounts are not new Been used for Access control, recurring crypto payments etc forever, but they have UX and fee drawbacks. --- ## Goal is to combine the two account types while keeping functionality - :question: [EIP-3074 Account delegation](https://eips.ethereum.org/EIPS/eip-3074) - :heavy_check_mark: [EIP-4337 Account abstraction](https://eips.ethereum.org/EIPS/eip-4337) --- ## Prior work  <small>Source https://arxiv.org/pdf/2309.00448</small> --- ## Middle ground All EIPs so far introduce high complexity, sigcheck modifications or other components subject to miner acceptance X_X --- ## Second mempool approach  --- We need a contract wallet, but a generic one so we don't have to re-implement every functionality: ```solidity! struct UserOperation { address to; bytes data; uint256 value; uint256 gas; uint256 nonce; bytes sig; } contract Wallet { function executeOp(UserOperation op); } ``` --- What about gas?  <small>Source: alchemy.com</small> --- What if you swallow my refund?  <small>Source: alchemy.com</small> --- Cherries on top: - Tx batching (BLS using BN254) - Paymasters :tada: - pay your gas in ERC20 or even fiat when combined with SIWE --- Major usecases: - Batching - Multisig - Intent-based txs - Gas-free transactions - Social recovery of lost keys - Recurring payment - Onchain subscriptions - Asset lending --- ## Current state of AA  <small>source: dune.com</small> ---  <small>source: dune.com</small> ---  <small>source: dune.com</small> ---  Visa is heavily experimenting with the paymaster functionality --- ## Security issues solved - Tx ordering & MEV - Bundler - Timestamp randomness - Bundler - Address validation - Entrypoint - Gas bounds - Paymaster - Reentrancy :tada: - Paymaster - Trapdoor contracts - Bundler - Selfdestructs - Entrypoint - origin manipulation - Bundler --- ## Security isses to remain - Business logic bugs - Block hash manipulation & other randomness - Empty account DoS (https://eips.ethereum.org/EIPS/eip-158) - Stack limit DoS - Uninitialized vars & inconsistent returns - Type errors --- ## New security issues introduced - Mutually untrusted parties change state in the same Tx - Authentication is split between the entrypoint and offchain code - Paymasters follow a reputation system which is always gamified - AA wallets need their own replay protection - More difficult to calculate exact gas cost of UserOps - Gamification of locked funds --- - Paymaster failures can still induce charges on wallets :warning: - Possible to DoS the paymasters if `postOp` hooks are not run - Trapdoor paymasters could spend locked funds :warning: - Token Transfers can fail with no trace :warning: --- ## Conclusion - AA could be the missing key to mass adoption with better UX - But as usual, better UX implies more complex security and threat models - Time-to-market is a strong force, and security always comes last - == Expect a bunch of AA hacks :smirk: --- ## Thanks for your attention! Slides are online:  https://silur.dev  @Huohuli