Version 0.1.0

Deployment information

Source code: https://github.com/Cardinal-Cryptography/zkOS-monorepo/releases/tag/v0.1.0

Testnet Contracts:

Mainnet Contracts:

Basic Information

This is the first release, considered beta, and thus it has several limitations aimed to provide protection for users while the code awaits a full audit and a few features are still under active development. The following list characterizes Version 0.1.0, with most of the restrictions expected to be lifted in the next release:

  1. Only AZERO is supported for shielding. Stable coins and ERC20 tokens are not yet supported.

  2. There is a limit of maximum 100 AZERO to be deposited at once. Also, the user interface (Common App browser Extension) does not allow a user to hold more than 100 AZEROin the shielded account, at any time.

  3. Instead of the mechanism with Anonymity Revokers (Anonymity Revokers), another scheme with limited privacy is used in this release (see PoW Anonymity Revoking). This will be replaced by the proper mechanism in the subsequent version.

  4. The access to Shielder is fully permissionless and there are no Registrars (see ZK-ID and Registrars), this means anybody can create an account and there are no additional requirements.

Technical Information on Circuits

While awaiting a full audit, the source code of the Halo2 circuits that we use stays in a private Github repository. The code of circuits will be published after the audit is finished and all findings have been addressed.

Notes and Hashing

For this release the structure of the note is as follows:

struct Note {
    version: Scalar, // version of the note structure. We start at 0
    id: Scalar, // the ZK-ID of a user
    trapdoor: Scalar, // a secret needed to prove ownership of the note
    nullifier: Scalar, // a secret used to invalidate the note
    balance_hash: Scalar, // the hash of the user's balance
} 

Specifically

balance_hash = hash(balance, 0, 0, 0, 0, 0, 0)

Where balanceis the user's AZERObalance — it is followed by 6zeros before hashing (using Poseidon2 Hash). The reason for including the zeros, is to make it possible for a quite simple migration to a version that supports a limited number of ERC20 tokens (they would populate the 6 zeros). Since the maximum constant-arity Poseidon2 Hash that we support in out circuits is 7the 6zeros is the most natural choice.

The Noteis then hashed simply as:

hash(version, id, trapdoor, nullifier, balance_hash)

using a 5-aryPoseidon2 Hash.

Circuits and Constraints

Apart from some changes in hashing (explained above) the circuits in Version 0.1.0 mostly follow the PoC Version — see PoC. The only significant difference is related to the introduction of:

  • Versioning. Starting with this initial release each note has a version. We refer to #versioning for a detailed discussion on that.

  • PoW Revoking. We refer to PoW Anonymity Revoking.

Last updated