# Private AA and Client-Side Proving

## Introduction

In [this tweet](https://x.com/VitalikButerin/status/1992115191278964752) Vitalik Buterin describes a vision of using an Ethereum account for "private account abstraction" (or "private AA" further on). Currently, both privacy and account abstraction can already be achieved on Ethereum, but only a few projects try to combine them. However, the key point in the original tweet is the ability to control the private AA account using an existing Ethereum account. Why is this important and what are the challenges?

*Short answer: Ethereum-controlled private AA allows to reuse the existing signing infrastructure (from browser wallets to multisigs and hardware wallets), but ZK-enabled privacy doesn't go well with the cryptography of Ethereum signing.*

Ethereum is using ECDSA over secp256k1 curve for signing which is not ZK-friendly.

> [!Warning] This is not about ERC-4337/ERC-7702
> The term account abstraction here is used in its most general meaning, which is controlling the actual transacting account indirectly (and in this particular case by means of another Ethereum account).

## Why signing is important?

In a typical "private pool" you control your funds with a private key [that is "exotic" to Ethereum](https://ethereum-magicians.org/t/thoughts-on-privacy-adoption-via-shielded-pools/26559/2), but is ZK-friendly. The problems with that are the following:
- you need to manage that key alongside with your existing Ethereum private key;
- even if you don't mind the former, you won't be able to re-use the existing signing infrastructure (software/hardware wallets, multisigs) to manage that key.

## What would change if the controlling key was an Ethereum key?

Let's consider a simple example of you trying to swap on Uniswap. Let's first take a look at the case when you're using your EOA directly:

### Using conventional EOA

sequenceDiagram
    participant U as User
    participant D as Uniswap UI
    participant W as Wallet (EOA)
    participant C as Uniswap Pool

    U->>D: choose swap
    D->>W: eth_sendTransaction
    W->>U: show tx details
    U-->>W: approve tx
    W->>W: sign tx (ECDSA)
    W->>C: send signed tx
    C-->>D: transaction receipt
    D-->>U: show result

You are signing the transaction with you Ethereum key - as intended by the system, but without any privacy. However, you can use any wallet to do that, including multisigs and hardware wallet.

### Using "conventional" private pools

Imagine you wanted to use your private (shielded) funds to conduct a swap. Why do most of the existing private pools don't have it, and only a few have it built-in in a special section of their UI? Because you cannot "connect your private pool" to Uniswap in a similar way you "connect" your EVM wallet. As in the normal tx (diagram above), at some point the transacting account would have to sign the transaction. To transact on behalf of a private pool, you would need to authorize the spending with your *exotic private pool key* - this cannot happen in your EVM wallet. If this is happening somewhere else, it becomes an extra attack vector: are you sure you are really signing this EVM transaction, or a malicious UI has modified it? will a 3rd party implement a wallet you can trust for signing with exotic keys? - probably no because it's privatepool-specific. Will a 3rd party implement a hardware wallet for signing and managing the exotic private pool key? - even less likely. Even if we don't view it as an attack surface, manual key management is simply a big UX disadvantage - where do you store the exotic private pool key? Why can't you do everything with a single EVM key instead of requiring both the EVM key and the exotic pool key?

### Using a private AA wallet controlled by an EVM key

Consider a private AA wallet built on top of a privacy pool. A potential architecture of such pool+wallet is described [here](https://ethresear.ch/t/smart-contract-or-eoa-spend-authority-for-private-accounts/23422). Let's see what the swap would look like when using such system:

sequenceDiagram
    participant U as User
    participant D as Uniswap UI
    participant PW as Private Wallet
    participant P as Prover
    participant R as Relayer
    participant PA as PrivateAA
    participant C as Uniswap Pool

    U->>D: choose swap
    D->>PW: provide swap params
    PW->>U: request EIP-712 signature
    U-->>PW: sign authorization
    PW->>P: send auth and params
    P-->>PW: return zk proof
    PW->>R: prepare tx for PrivateAA
    R->>PA: call swap(proof)
    PA->>C: call Uniswap swap
    C-->>PA: swap executed
    PA-->>R: tx success
    R-->>PW: included
    PW-->>U: show private result

> *TODO worth unpacking the architecture from https://ethresear.ch/t/smart-contract-or-eoa-spend-authority-for-private-accounts/23422, but with accent on client-side proving and on the approach of deriving the proving key from the EVM key*

When you hit "Swap", Uniswap sends an EIP-712 intent payload to your browser. Instead of signing it with your EOA (as in the first diagram), your private-AA middleware would intercept it and ask you to sign a [SpendAuthorization message](https://ethresear.ch/t/smart-contract-or-eoa-spend-authority-for-private-accounts/23422) for the private-AA pool using a standard EVM signature - you can do it with any existing wallet, including multisigs and hardware wallets. This signature is never broadcast; it is used inside a ZK proof to show that your EVM account privately authorized this exact action.

Next, the private-AA middleware generates a ZK proof that:
- you own sufficient private notes,
- the SpendAuthorization hash is committed in the PrivateAA Merkle tree,
- the signature is valid (without revealing your address),
- the calldata matches the authorization,
- nullifiers prevent double-spending.

The proof is sent to a relayer, which submits an Ethereum transaction to the PrivateAA contract.
PrivateAA contract verifies the proof and executes the Uniswap swap on-chain on your behalf.

The result is a full Uniswap swap with normal UX ("connect wallet -> sign -> swap") - check out [this Bermuda demo](https://x.com/bermudabayzk/status/1992288803982110746?s=20).

## Off-Chain App Interaction

Imagine an offchain app (Zupass, a forum, a chatroom, a DEX offchain matcher, etc.)

1. App sends an "authorization challenge"

op = {
   domain: app.example.com,
   action: "login",
   timestamp: 2025-01-01,
   nonce: 123,
}

2. PrivateAA wallet signs this challenge with EVM control key

(This signature stays private.)

3. Wallet generates a ZK proof of:
- "I have a valid SpendAuthorization for this challenge"
- "Signed by a valid Ethereum account"

Without revealing the account

4. App verifies proof. The app now knows:
- "This user controls some Ethereum account"
- "This account authorized this login"
- "I don’t know which one”
- "I can’t link this login to any other login unless the user wants that"

This transforms your Ethereum key into a private, non-linkable root-of-trust for offchain auth.

sequenceDiagram
    participant U as User
    participant A as Offchain App
    participant PW as Private Wallet
    participant P as Prover

    A->>PW: send challenge {domain, action, timestamp, nonce}
    PW->>U: display login request
    U-->>PW: approve (EIP-712 signature via PW)
    PW->>P: generate ZK proof (auth bound to challenge)
    P-->>PW: return zk proof
    PW-->>A: submit zk proof
    A->>A: verify proof (authorize user)

## What about client-side proving?

According to our benchmarks, performant ECDSA proving is possible on the client-side today [in sub-seconds (e.g., with Barretenberg)](https://ethproofs.org/csp-benchmarks), to the contrary of ~10 minutes that [some researchers are stating](https://ethereum-magicians.org/t/thoughts-on-privacy-adoption-via-shielded-pools/26559). Therefore, building private AA wallets controlled by an EVM account is feasible today.

## References

- https://ethereum-magicians.org/t/thoughts-on-privacy-adoption-via-shielded-pools/26559
- https://ethresear.ch/t/smart-contract-or-eoa-spend-authority-for-private-accounts/23422