Version 0.2.0

Deployment Information

Deployment scheduled after audit is complete.

Basic Information

This is the second release. It is deployed via a new set of contracts to avoid any backward compatibility issues. With respect to Version 0.1.0 the main changes are the following:

1. The Anonymity Revoking is implemented as in Anonymity Revokers and this replaces the PoW Anonymity Revoking that was used as a temporary solution.

2. Aside from the native token, it is possible to shield arbitrary ERC20 tokens.

3. Support for deploying on other EVM chains.

Details in Circuits

ERC20

Previously we had:

struct Account {
    balance_NATIVE: Scalar, 
}

fn hash(a: Account) -> Hash {
    poseidon2(a.balance_Native, 0, 0, 0, 0, 0, 0)
}

Now to support ERC20 we change the account structure to:

struct Account {
    balance: Scalar,
    token_id: Scalar, // address (160 bits) encoded into a field element (~254 bits) 
}

fn hash(a: Account) -> Hash {
    poseidon2(a.balance, a.token_id, 0, 0, 0, 0, 0)
}

Valid transitions between old: Accountand new: Account apart from the usual constraints must also include old.token_id == new.token_id. We use the convention that token_id = 0represents the native token.

All notes still live in a single Merkle tree, only the accounts are now more general.

Anonymity Revoking

Details are provided in Anonymity Revoking. The new account transaction emits an encrypted key(id) (see SNARK-friendly Asymmetric Encryption for how this is done) for the AR, and subsequently each transaction emits a MAC based on this key. We note that because the old contract is not migrated, and instead a new is deployed, this allows us to skip the step when old accounts emit their encrypted key(id)(because they didn't do it in Version 0.1.0).