# User Wallet

In this section we sketch how a user wallet could work, i.e., what kind of state would it need to store, how to retrieve the state and how to make new transactions. We assume [deterministic-secret-management](https://docs.alephzero.org/aleph-zero/protocol-details/shielder/deterministic-secret-management "mention") is used.

## Current State and Creating Transactions

The current state of the user consists of:

* `seed` -- the master seed used to derive all secrets
* `id` -- the ZK-ID of the user
* Current note:
  * `trapdoor`
  * `nullifier` 
  * `account` -- the current account state

Given all the above it's possible to update the state with the `update_note` transaction, as explained in [notes-and-accounts](https://docs.alephzero.org/aleph-zero/protocol-details/shielder/notes-and-accounts "mention") (or the adjusted version in [anonymity-revokers](https://docs.alephzero.org/aleph-zero/protocol-details/shielder/anonymity-revokers "mention")) indeed the reader is encouraged to check that all the proofs necessary to craft a new transactions can be generated using the data listed above.

## Restoring the State from the master seed

The whole premise behind using a single master `seed` is that the user can recover the entire state as above just from the `seed` and the on-chain data. Of course the recovery process might be lengthy, but should be possible. On the other hand, for everyday operation the user is supposed to keep its current state, and preserve it, for efficiency. 

Recovering the current state of a user consists of several steps:

1. Generate the ZK-ID `id` of the user deterministically from `seed`
2. Compute the key `key=key(id)`
3. Obtain the chronological list of all transactions `tx_1, tx_2, ... tx_n` that were finalized on chain:
   * To this end filter the list of all transactions sent to the shielder from all users. The filtering rule is as follows:
     * let `tx` be a transaction
     * let `mac = (m_0, m_1)` be the mac of `tx`
     * If `m_1 = hash(m_0, key)` then keep the `tx` as it means it belongs to the user
   * (Note that this step is quite inefficient as written, below we explain how one can go about improving the efficiency).
4. `tx_1` is the `new_note` transaction and can be thus ignored. For the remaining ones perform the following procedure to recover the current `account`. 
   1. Set `account := Account::new()`
   2. For `tx` in `[tx_2, tx_3, ..., tx_n]` do:
      1. Extract `op_pub` out of `tx`
      2. Extract `op_priv` out of `e_op` using the key `key` to decrypt it
      3. Combine `op = combine(op_pub, op_priv)`
      4. Update the account `account = Account::update(account, op)`
5. Derive the `trapdoor` and `nullifier` of the last note deterministically from `seed`

## Improving the collection phase

To collect all transactions relevant to the account one has to filter all shielder transactions which is quite slow. There are several ideas on how to improve upon that:

1. To the `n`th shielder transaction of a user attach an encrypted (using `SymEnc` with key `key(id)`) number `k` being the block number where the `n-1`th transation landed. This way the only thing the user needs to do is: find its last transaction, and scan `n` blocks in total.
2. Use fuzzy message detection techniques.