Knowledge Base
  • Introduction
  • SHIELDING
    • Shielded pools
    • Key generation process
    • Privacy best practices
  • Fraud protection
  • Web App – User Guide
  • SMART YIELD
    • How does Smart Yield work?
    • Governance Model
    • Shielding
  • COMMON ECONOMY
    • The Economy of Common
    • CMN Token
    • CMN Tokenomics and Vesting Schedules
    • CMN Airdrops
    • Shared Fees and Reward Economics of Common
  • Wallet (Extension)
    • Introduction
    • Getting Started
    • Usage
    • Settings
  • DEX and Bridge (Aleph Zero WASM layer 1)
    • Account
      • How to Connect Your Wallet
      • Video Guide: How to Connect Your Wallet
      • How to Check Your Balance
      • Video Guide: How to Check Your Balance
    • Swap
      • How to Swap Tokens
      • Video Guide: How to Swap Tokens
    • Farm
      • How to Farm
      • Video Guide: How to Farm
    • Pool
      • Explaining Liquidity Pools
      • Video guide: Explaining Liquidity Pools
      • Managing Liquidity Pools with Custom Tokens
      • Video Guide: Managing Liquidity Pools with Custom Tokens
    • Bridge
      • How to Bridge With Most
        • Ethereum to Aleph Zero WASM
        • Aleph Zero WASM to Aleph Zero EVM
      • Video Guide: How to Bridge With MOST?
      • Bridging 10,000+ AZERO from Aleph Zero WASM to EVM
  • Protocol Details
    • Shielder
    • Overview
    • Design Against Bad Actors
    • Preliminaries: ZK Relations
    • Notes and Accounts
    • ZK-ID and Registrars
    • Anonymity Revokers
    • PoW Anonymity Revoking
    • Relayers
    • Deterministic Secret Management
    • SNARK-friendly Symmetric Encryption
    • SNARK-friendly Asymmetric Encryption
    • Cryptography
    • Token Shortlist
    • User Wallet
    • Versioning
    • PoC
    • Version 0.1.0
    • Version 0.2.0
Powered by GitBook
On this page
  • Current State and Creating Transactions
  • Restoring the State from the master seed
  • Improving the collection phase

Was this helpful?

  1. Protocol Details

User Wallet

PreviousToken ShortlistNextVersioning

Last updated 5 days ago

Was this helpful?

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 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 (or the adjusted version in ) 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 nth shielder transaction of a user attach an encrypted (using SymEnc with key key(id)) number k being the block number where the n-1th 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.

Deterministic Secret Management
Notes and Accounts
Anonymity Revokers