Account Abstraction

Issues with Current Wallet Management

  • Difficulties in handling private keys

  • Costs associated with gas fees

  • Privacy preservation challenges

  • Dependency on middleman smart contracts for multiple transactions

Introduction to Account Abstraction

  • Traditional transactions require private key to sign data

  • Account abstraction allows signing data with various methods

  • Possible authentication methods:

    • Google account

    • GitHub account

    • Social confirmation (friends' approval)

    • Time-based limitations

    • Spending limits

  • Flexibility: Private key equals wallet changes to anything as wallet

Benefits of Account Abstraction

  • Customizable wallets (parental controls, approval systems)

  • Third-party payment for transactions (no need for personal gas fees)

How Account Abstraction Works

  • Two implementations: Ethereum (Entrypoint smart contract) and ZK Sync (native support)

  • Overview of the Entrypoint on Ethereum

    • Deploy smart contract to define signing methods

    • Sign with approved method (Google, friends, etc.)

    • Send user operation to alt mempool instead of Ethereum node

    • Alt mempool nodes validate and send transaction on-chain

    • Alt mempool nodes pay for gas (with conditions)

    • ERC 4337 framework and handleOps function of entrypoint smart contract

  • ZK Sync's native Account Abstraction

    • Default accounts assume smart contracts for all addresses

    • No need for separate alt mempool nodes

    • Simplified process compared to Ethereum

Additional Components of Account Abstraction

  • Signature Aggregator: Aggregates multiple signatures for multi-sig setups

  • Pay Master: Allows defining who will pay for transactions, not necessarily the account owner