ZEOS Action Circuit

As in Zcash Orchard there is only one circuit which is used to generate proofs for all privacy actions. The ZEOS Orchard circuit, , is very similar to the Zcash Orchard circuit. It can be divided into three parts: A, B and C. Each circuit part represents a UTXO and the action circuit describes their relationship to each other. There are two main configurations for this circuit.

It is either:

or

The first configuration is used for all transfer and burn actions. UTXO represents the note which is being spent by the action. UTXO represents the receiving part of the action whereas UTXO represents the 'change' which goes usually back into the wallet of the sender (spender of UTXO ). Hence the relation between the UTXOs.

In case of NFT transfers (or burns) UTXO is always zero which enforces . This statement must be true for NFT transfers since NFTs are not divisable.

The second configuration is used for minting notes only. The configuration effectively disables the circuit parts and leaving only part enabled.

See also:

  • the schematic of the action circuit (TODO: Legend)
  • the layout of the action circuit (column types explained here)

Private Inputs ()

The following list contains all private inputs to the top level ZEOS action circuit.

Note (action input):

  1. : Authentication path of note commitment A. The sister path of note commitment A which is required in order to calculate it's merkle plath.
  2. : Position of note commitment A inside the merkle tree. Specifically this is the leaf index of note commitment A.
  3. : Address diversify hash of note A. Deterministically derived from a diversifier index (see p. 37 Zcash Protocol Specification).
  4. : Address public key of note A. Derived from Incoming Viewing Key and diversify hash (see p. 14 and 37 Zcash Protocol Specification).
  5. : Either the value of note A (fungible token) or the (lower 64 bits of the) unique identifier of note A (non-fungible token).
  6. : Either the symbol code of note A (fungible token) or the (upper 64 bits of the) unique identifier of note A (non-fungible token).
  7. : Randomness to derive nullifier of note A (equals nullifier of note that was spent in order to create note A) (see p. 14 Zcash Protocol Specification)
  8. : Additional randomness to derive nullifier of note A (see p. 14 Zcash Protocol Specification)
  9. : Random commitment trapdoor of note commitment A (see p. 14 and 28 Zcash Protocol Specification)
  10. : Note commit of note A (see p. 28 Zcash Protocol Specification).
  11. : Randomness to derive a spend authorization signature for note A (see p. 55 Zcash Protocol Specification).
  12. : Spend Validating Key which is part of the Full Viewing Key components (see p. 36 and 116 Zcash Protocol Specification).
  13. : Nullifier Deriving Key which is part of the Full Viewing Key components (see p. 36 and 116 Zcash Protocol Specification).
  14. : Randomness which is part of the Full Viewing Key components to derive corresponding Incoming Viewing Key of the address diversify hash of note A (see p. 36, 37 and 116 Zcash Protocol Specification).

Note (action output):

  1. : Address diversify hash of note B.
  2. : Address public key of note B.
  3. : Either the value of note B (fungible token) or the (lower 64 bits of the) unique identifier of note B (non-fungible token).
  4. : Either the symbol code of note B (fungible token) or the (upper 64 bits of the) unique identifier of note B (non-fungible token).
  5. : The code of the smart contract issuing notes A, B and C.
  6. : Randomness to derive nullifier of note B (equals nullifier of note A).
  7. : Additional randomness to derive nullifier of note B.
  8. : Random commitment trapdoor of note commitment B.
  9. : Code of EOS account in which this note is 'burned'.

Note (action output):

  1. : Address diversify hash of note C.
  2. : Address public key of note C.
  3. : Value of note C (fungible token only).
  4. : Additional randomness to derive nullifier of note C.
  5. : Random commitment trapdoor of note commitment C.
  6. : Code of EOS account in which this note is 'burned'.

Public Inputs ()

The following list contains all public inputs to the top level ZEOS action circuit.

  1. : Merkle tree root of authentication path of note A (see p. 17 to 19 Zcash Protocol Specification).
  2. : Nullifier of note A (see p. 56 Zcash Protocol Specification).
  3. : Spend Authority (x component) of (, ) (see p. 61 Zcash Protocol Specification).
  4. : Spend Authority (y component).
  5. : Indicates if notes in circuit represent NFTs or fungible tokens.
  6. : Exposes value (fungible token) or unique id (non-fungible token) of note B in case of MINT or BURN.
  7. : Exposes symbol (fungible token) or unique id (non-fungible token) of note B in case of MINT or BURN.
  8. : Exposes smart contract code of note B in case of MINT or BURN.
  9. : Exposes value of note C in case of BURNFT2 (fungible tokens only).
  10. : Note commitment of note B.
  11. : Note commitment of note C.
  12. : Code of EOS account into which note B is 'burned'.
  13. : Code of EOS account into which note C is 'burned'.

Circuit Internal Signals

The following signals are circuit-internal only.

  1. : Derived root of merkle path of note A.
  2. : Derived commitment of note A.
  3. : Derived address public key of note A.
  4. : Derived spend authority (x component) of note A.
  5. : Derived spend authority (y component) of note A.
  6. : Derived nullifier of note A.
  7. : Derived commitment of note B.
  8. : Derived commitment of note C.

Constraints

Constraining an arithmetic circuit in Halo 2 is very similar to integrated circuit design in computer engineering. All Constraints are expressed as mathematical equations evaluating to zero. The logical AND becomes a multiplication and the logical OR becomes an addition.

The following statements for private and public inputs must hold.

The global statement 'either or ' results in the following constraint for the note values :

For circuit part A the following constraints must hold:

For circuit part B the following constraints must hold:

For circuit part C the following constraints must hold:

Valid Circuit Configurations

The following table lists the zactions and the corresponding configurations of the circuit's public inputs .

MINTFT

Given:
because of internal signals (1), (4), (5), (6) and constraints (2), (5), (6) and (8)

Given:
because of internal signal (7)

Given:
because of constraint (1)

Given:
because of constraint (13)

Given:
because of constraint (17)

MINTNFT/BURNAT

Note: The actions MINTNFT and BURNAT share the exact same circuit configuration.

Given:
because of internal signals (1), (4), (5), (6) and constraints (2), (5), (6) and (8)

Given:
because of internal signal (7)

Given:
because of constraints (1) and (14)

Given:
because of constraint (13)

Given:
because of constraint (17)

TRANSFERFT

Given:
because of internal signals (1), (4), (5), (6) and constraints (2), (5), (6) and (8)

Given:
because of constraint (1)
because of constraint (7)
because of constraint (8)

Given:
because of constraint (13)

Given:
because of constraint (17)

TRANSFERNFT

Given:
because of internal signals (1), (4), (5), (6) and constraints (2), (5), (6) and (8)

Given:
because of constraint (14)

Given:
because of constraint (1)

Given:
because of constraint (7)
because of constraint (8)

Given:
because of constraint (13)

Given:
because of constraint (17)

BURNFT

Given:
because of internal signals (1), (4), (5), (6) and constraints (2), (5), (6) and (8)

Given:
because of constraint (1)
because of constraint (7)
because of constraint (8)

Given:
because of constraint (17)

BURNFT2

Given:
because of internal signals (1), (4), (5), (6) and constraints (2), (5), (6) and (8)

Given:
because of constraint (1)
because of constraint (7)
because of constraint (8)

BURNNFT

Given:
because of internal signals (1), (4), (5), (6) and constraints (2), (5), (6) and (8)

Given:
because of constraint (14)

Given:
because of constraint (1)

Given
because of constraint (7)
because of constraint (8)

Given:
because of constraint (17)