ZEOS Orchard

This is the main application of the ZEOS protocol for private and untraceable transactions on the EOS Blockchain. This application will be deployed to the EOS Mainnet.

See also:

• The ZEOS Book (including a full protocol specification)
• Token Contract (Orchard)
• JS Wallet (Orchard)

Description

This repository is a fork of Zcash Orchard. The application enables Zcash-like shielded transactions of fungible and non-fungible tokens on the EOS blockchain. Check out the Whitepaper for more Information.

This application is built on EOSIO and Liquidapps' DAPP Network services.

Getting Started

To setup the full workspace clone the dependencies rustzeos, halo2, pasta_curves, reddsa, the smart contract and the JS wallet as well:

mkdir zeos
cd zeos
git clone https://github.com/mschoenebeck/rustzeos.git
git clone https://github.com/mschoenebeck/halo2.git
git clone https://github.com/mschoenebeck/pasta_curves.git
git clone https://github.com/mschoenebeck/reddsa.git
git clone https://github.com/mschoenebeck/thezeostoken.git
git clone https://github.com/mschoenebeck/zeos-verifier.git
cd thezeostoken && git checkout orchard && cd ..
git clone https://github.com/mschoenebeck/zeos-wallet.git
cd zeos-wallet && git checkout orchard && cd ..

Clone this repository:

git clone https://github.com/mschoenebeck/zeos-orchard.git
cd zeos-orchard

Build the project as Rust library:

cargo build

Dependencies

• Rust Toolchain

Help

If you need help join us on Telegram.

Authors

Matthias Schönebeck

License

Copyright 2020-2022 The Electric Coin Company.

You may use this package under the Bootstrap Open Source Licence, version 1.0, or at your option, any later version. See the file COPYING for more details, and LICENSE-BOSL for the terms of the Bootstrap Open Source Licence, version 1.0.

The purpose of the BOSL is to allow commercial improvements to the package while ensuring that all improvements are open source. See here for why the BOSL exists.

Acknowledgments

Big thanks to the Electric Coin Company for developing, documenting and maintaining this awesome open source codebase for zk-SNARKs!

• Zcash Protocol Specification

Introduction

The protocol presented here is a fork of the Zcash Orchard Shielded Protocol, but tailored for EOSIO/Antelope blockchains and their asset classes. One of the key differences to Zcash is that the ZEOS Orchard Shielded Protocol is implemented as a smart contract on a general purpose blockchain (rather than as a stand-alone application on its own blockchain). Deployed on a public blockchain like the EOS mainnet, it exists as one of many applications in a diverse ecosystem. This makes it desirable to enable not only private peer-to-peer transactions, as with Zcash, but also private peer-to-contract transactions.

This makes the ZEOS Orchard Shielded Protocol much more sophisticated than the original version of Zcash. After all, there is only one fungible token on the Zcash blockchain - the native Zcash cryptocurrency - and no smart contracts at all. On EOSIO/Antelope blockchains, however, there are countless tokens with different symbols and precision, which are even issued and managed by different smart contracts. Finally, there are even different token types, such as fungible and non-fungible tokens.

This increased complexity in an environment of general-purpose blockchains such as EOSIO/Antelope also inevitably increases the requirements for a protocol for private transactions on such smart contract platforms. The ZEOS Orchard Shielded Protocol provides a fully comprehensive solution for user privacy in such an environment. Implemented and deployed as an application on a public blockchain such as EOS, it allows users to remain completely anonymous in their daily interactions with decentralized applications.

The ZEOS Orchard Shielded Protocol enables private DeFi on EOSIO/Antelope blockchains.

Preliminaries

This work is based on a thorough study of the following protocols and applications:

• Nightfall: A protocol for private peer-to-peer transactions on Ethereum based on zk-SNARK.
• Zcash Sprout
• Zcash Sapling
• Zcash Orchard

Related Research:

• Monero: A protocol for private peer-to-peer transactions based on Stealth Addresses, Ring Signatures, and RingCT.
• Dero: A protocol for private peer-to-peer transactions based on Homomorphic Encryption.

Zcash Protocol Specification

Since the protocol presented here is a fork of the Zcash Orchard Shielded Protocol the same specification applies almost everywhere. Only differences/extensions of the original protocol are specified here. Thus there are a lot of references to the original Zcash Protocol Specification.

ZEOS Whitepaper

The ZEOS whitepaper contains a first version of the concepts specified here. However, it was written in regards to the Groth16 proving system while the protocol presented here is based on the Halo2 proving system. The concepts described there are still mostly valid though.

Terminology

The terminology used is based on that of Nightfall and Zcash. The abbreviation 'UTXO' means 'Unspent Transaction Output' and is used interchangably with the term 'note'. The terms 'mint' and 'burn' refer to the creation (mint) or nullification (burn) of UTXOs (aka notes). The term 'ZEOS smart contract' refers to an EOSIO/Antelope smart contract that implements the ZEOS Orchard Shielded Protocol as specified here.

Introduction Video

The following video gives a short introduction to the features of the Zcash Orchard Shielded Protocol by the leading developers Sean Bowe and Daira Hopwood.

Overview

The ZEOS Orchard Shielded Protocol specifies a non-traceable UTXO transaction model implemented in an EOSIO/Antelope smart contract. This means that private ZEOS wallets do not exist directly in blockchain RAM - like EOSIO/Antelope accounts, for example - but only in the form of UTXOs that are assigned to specific wallet addresses. Users can therefore - as with any legacy cryptocurrency - simply create a new ZEOS wallet by picking a large random number (aka private key).

All assets held in private ZEOS wallets are actually in custody of the ZEOS smart contract. In order to transfer an asset from a transparent EOS account to a private ZEOS wallet, it is actually transferred to the ZEOS smart contract, while at the same time a (private) UTXO is minted, assigned to a private ZEOS wallet address specified by the user. UTXOs can then be transferred completely anonymously between ZEOS wallets without their ownership being traceable on chain.

The only data managed by the ZEOS smart contract are cryptographic commitments of valid UTXOs and their nullifiers. The validity of commitments and nullifiers is proven to the public using zero knowledge proofs (more precisely: zk-SNARKs) without revealing any sensitive information about the private UTXOs themselves.

Analogous to minting, UTXOs can also be burned in order to transfer assets from private ZEOS wallets back to a transparent EOS accounts. By burning the corresponding UTXO, the underlying asset is freed from custody of the ZEOS smart contract and transferred to an EOS account specified by the user. Using mint and burn actions, assets can be moved between transparent EOS accounts and private ZEOS wallets.

Privacy therefore only exists for assets "inside" the ZEOS application - i.e. only for assets in custody of the ZEOS smart contract and represented by UTXOs in private ZEOS wallets. The underlying EOSIO/Antelope blockchain remains transparent, of course. However, the introduction of a so-called authenticator token enables private token deposits and withdrawals. This means that users are able to interact directly from their ZEOS wallets with third party smart contracts of the same EOSIO/Antelope blockchain - as long as those contracts implement the necessary interface of the ZEOS Orchard Shielded Protocol.

The introduction of the authenticator token and the private deposits and withdrawals it enables make the ZEOS Orchard Shielded Protocol a truly universal privacy solution for EOSIO/Antelope blockchains that offers users of private ZEOS wallets almost the same blockchain experience as users of transparent EOS accounts - but with complete privacy.

See the ZEOS Whitepaper for more information about the concepts of the protocol presented here.

Keys & Addresses

The entire underlying cryptography of the protocol is identical to Zcash Orchard and is precisely specified in the Zcash Protocol Specification. The key and address derivation is thus also exactly identical to Zcash Orchard. The only difference is that there are no transparent UTXOs in the ZEOS Orchard Shielded Protocol and thus no unshielded transactions. The newly introduced concept of 'Unified Payment Addresses' in Zcash is therefore not adopted. In ZEOS there are only 'Shielded Payment Addresses'.

For a detailed explanation of all key components, please refer to the Zcash Protocol Specification, section 3.1 and section 4.2.3 respectively. In this document only the most important parts are briefly discussed. All key components are 32 bytes long.

Spending Key

The Spending Key $\mathsf{sk}$ is a randomly chosen number from which all further key material is derived. Since the introduction of BIP 32 and ZIP 32, respectively, spending keys are usually derived deterministically from long, human readable seed phrases via pseudo-random function.

Full Viewing Key

The Full Viewing Key $\mathsf{fvk}$ is the actual set of keys needed to generate private transactions. It is derived directly from the Spending Key and consists of three sub-keys:

• $\mathsf{ak}$ - Spend Validating Key
• $\mathsf{nk}$ - Nullifier Deriving Key
• $\mathsf{rivk}$ - ${\mathsf{Commit}}^{\mathsf{ivk}}$ Randomness

This key represents the minimum authority needed to spend UTXOs.

Incoming Viewing Key

The Incoming Viewing Key $\mathsf{ivk}$ can be used to detect incoming payments (i.e. received UTXOs), but not to spend them. This key can be used, for example, for payment terminals to be able to confirm successfully received payments to customers.

In addition, each UTXO has a unique Viewing Key that can be shared by the sender with others in order to prove that a transmitted UTXO has been received.

Outgoing Viewing Key

The Outgoing Viewing Key $\mathsf{ovk}$ can be used to detect all sent payments (i.e. spent UTXOs) of a wallet.

Shielded Payment Address

An Orchard Shielded Payment Address is 43 bytes long and consists of:

• $\mathsf{d}$ - Diversifier (10 bytes)
• $\mathsf{p}{\mathsf{k}}_{\mathsf{d}}$ - Diversified Transmission Key (33 bytes)

Since Zcash Orchard it is possible to deterministically derive several diversified payment addresses from one and the same spending authority. A group of such addresses share the same Full Viewing Key, Incoming Viewing Key and Outgoing Viewing Key.

UTXOs (aka Notes)

While there is only one fungible token in Zcash - the native cryptocurrency ZEC - there is significantly more token diversity in EOSIO/Antelope ecosystems. The ZEOS Orchard Shielded Protocol defines three different UTXO types:

• Fungible Token (FT) Fungible tokens on EOSIO/Antelope blockchains are defined by the amount, symbol, and code of the smart contract (aka EOS account name) that issues them.

• Non-Fungible Token (NFT) NFTs on EOSIO/Antelope Blockchains mainly follow the AtomicAssets token standard and are thus defined by a unique identifier and code of the smart contract (aka EOS account name) that issues them. The latter is the atomicassets smart contract in most cases, but can also be a custom NFT contract that follows the same standard.

• Authenticator Token (AT) These tokens represent a permission to access specific assets in custody of a specific smart contract. They are characterized by the code of the respective smart contract and their $\mathsf{NoteCommit}$ value.

Tuple

To cover all three ZEOS token types, the Zcash Orchard Note Tuple (as defined in Section 3.2 of the Zcash Protocol Specification is extended to the following structure:

• $\mathsf{d}$ is the diversifier of the recipient’s shielded payment address
• $\mathsf{p}{\mathsf{k}}_{\mathsf{d}}$ is the diversified transmission key of the recipient’s shielded payment address
• $d1$ is an integer representing either the amount of the UTXO (fungible token) or the lower 64 bits of an identifier (non-fungible token)
• $d2$ is an integer representing either the symbol of the UTXO (fungible token) or the upper 64 bits of an identifier (non-fungible token)
• $\mathsf{sc}$ is an integer representing the code of the issuing smart contract
• $\mathsf{nft}$ is a boolean determining if this UTXO is a fungible token (FT) or non-fungible token (NFT or AT)
• $\rho$ is randomness used to derive the nullifier of the UTXO
• $\psi$ is additional randomness used in deriving the nullifier
• $\mathsf{rcm}$ is a random commitment trapdoor as defined in section 4.1.8 of the Zcash Protocol Specification

Note: In addition to the above listed attributes each UTXO struct contains a header field (64 bit) and a memo field (512 bytes).

Commitment

When UTXOs are created (through minting or transfer), only a cryptographic commitment called $\mathsf{NoteCommit}$ to the tupel attributes listed above is publicly disclosed and added to a global data structure called Commitment Tree. This allows the sensitive information such as amount, symbol, and recipient of the UTXO to be kept secret, while the commitment is used by the zk-SNARK proof to verify that the UTXO's secret information is valid.

Since the UTXO tuple has been extended for the ZEOS Orchard Shielded Protocol, the definition of the UTXO Commitment must also be modified. The original $\mathsf{NoteCommit}$ is defined in section 5.4.8.4 of the Zcash Protocol Specification. It is changed to:

$${\mathsf{NoteCommit}}_{\mathsf{rcm}}^{\mathsf{Orchard}}(\mathsf{g}{\star }_{\mathsf{d}},\mathsf{pk}{\star }_{\mathsf{d}},d1,\rho ,\psi ,d2,\mathsf{sc},\mathsf{nft}):={\mathsf{SinsemillaCommit}}_{\mathsf{rcm}}(\text{"z.cash:Orchard-NoteCommit"},\mathsf{g}{\star }_{\mathsf{d}}||\mathsf{pk}{\star }_{\mathsf{d}}||{I2LEBSP}_{64}(d1)||{I2LEBSP}_{{\ell }_{\mathsf{base}}^{\mathsf{Orchard}}}(\rho )||{I2LEBSP}_{{\ell }_{\mathsf{base}}^{\mathsf{Orchard}}}(\psi )||{I2LEBSP}_{64}(d2)||{I2LEBSP}_1(\mathsf{nft})||{I2LEBSP}_{64}(\mathsf{sc}))$$

Nullifier

Each UTXO has a unique nullifier which is deterministically derived from the UTXO tuple. Spending a UTXO invalidates it by publicly revealing the associated nullifier and adding it to the global set of all nullifiers called Nullifier Set. Analogous to the UTXO commitment, this way the sensitive information (amount, symbol, receiver) of the UTXO can be kept secret, while the nullifier is used by the zk-SNARK proof to check whether the nullifier is valid. That is, whether it actually nullifies an existing valid UTXO. Furthermore, the smart contract must check if the nullifier does not yet exist in the global set of all nullifiers to avoid double spends.

The exact function for deriving the nullifier is defined in section 4.16 of the Zcash Protocol Specification.

$$\mathsf{DeriveNullifie}{\mathsf{r}}_{\mathsf{nk}}(\rho ,\psi ,\mathsf{cm})=\mathsf{Extrac}{\mathsf{t}}_{\mathbb{P}}([(\mathsf{PR}{\mathsf{F}}_{\mathsf{nk}}^{\mathsf{nfOrchard}}(\rho )+\psi )\mathrm{mod}{q}_{\mathbb{P}}]{\mathcal{K}}^{\mathsf{Orchard}}+\mathsf{cm})$$

where $\mathsf{cm}$ is the $\mathsf{NoteCommit}$ value of the corresponding UTXO.

No modification is required, since it depends only on the UTXO randomness as well as its commitment. The latter has already been adapted to the new UTXO tuple structure (see Commitment).

In-band secret distribution of UTXOs

The sender of a UTXO must be able to transmit the sensitive information (i.e. the UTXO tuple) to the receiver. After all, these are required so that receivers of UTXOs can successfully spend them. Thus, a private communication channel is needed through which the sensitive UTXO tuples can be transmitted.

For this purpose, Zcash Orchard - like all existing privacy coins in the crypto space - uses the underlying blockchain itself: Each UTXO tuple is encrypted and its ciphertext uploaded to the blockchain where it can be fetched and decrypted by the receiver. For the ZEOS Orchard Shielded Protocol a global data structure called Transmitted UTXO Ciphertext List is maintained by the ZEOS smart contract in which UTXO ciphertexts can be added.

The use of this communication channel is optional. It is important to keep in mind that all encrypted UTXOs added to that list become part of the underlying EOSIO/Antelope blockchain history which never forgets. At some point in the future the currently used encryption scheme might become unsafe and thus privately transmitted UTXO ciphertexts using this on chain communication channel might become traceable. This is a general problem all privacy cryptocurrencies in existence today suffer from.

The exact encryption scheme based on Incoming, Outgoing and Full Viewing Key is described in section 4.19 of the Zcash Protocol Specification and is adopted exactly the same way for the ZEOS Orchard Shielded Protocol.

Global Data Sets

The ZEOS smart contract maintains the following global data sets which define the state of the UTXO transaction model.

Commitment Tree

The UTXO Commitment Tree is a merkle tree managed by the ZEOS smart contract. It is instantiated with the Sinsemilla hash function, which can be efficiently implemented in Halo 2 arithmetic circuits. The leaves of the tree contain all existing and thus valid UTXO commitments. Thus, each UTXO that is newly created either by minting or transfer has an associated commitment leaf in the merkle tree. The number of leaves in the tree defines the size of the so-called anonymity set, which is directly determined by the depth of the tree.

The tree is always filled from left to right. Depending on the depth of the tree, there is room for a certain amount of leaves per tree. When a tree is full, it 'overflows' to the right into a new, empty tree. Each time one or more leaves are added, the root of the tree is updated.

Commitment Tree Root Set

In addition to the tree itself, the ZEOS smart contract maintains a set of merkle nodes in which all valid tree roots that have ever been created are being recorded. This way, the anonymity set of the protocol can be easily configured via the merkle tree depth, without having to worry about how many trees exist at a given time or to which tree a certain leaf (aka UTXO commitment) belongs.

For a UTXO to be valid, the following must be true: There exists (or existed) a merkle path that leads (or led) to a valid merkle root. This must be proven via zero knowledge proof for a UTXO in order to be spent.

The Commitment Tree itself as well as the Commitment Tree Roots set are both part of the global UTXO transaction state.

Nullifier Set

The UTXO Nullifier Set maintains a list of all nullifiers that have been publicly exposed. Each nullifier invalidates a particular UTXO which prevents double spending. The validity of nullifiers must be proven via zero knowledge proof in order to be able to spend UTXOs.

The Nullifier Set is part of the global UTXO transaction state.

Transmitted UTXO Ciphertext List

This global list of transmitted UTXO ciphertexts is used for the In-band secret distribution of UTXOs. It is not part of the global UTXO transaction state and its usage is optional.

Arithmetic Circuit

Every privacy protocol based on zk-SNARKs is built around a so-called arithmetic circuit, which defines the constraint system based on which all zero knowledge proofs are generated. It is essentially a mathematical function $C$ that takes a set of private inputs $\omega$ and a set of public inputs $x$ and either resolves to $1$ (valid inputs) or $0$ (invalid inputs). The arithmetic circuit forms the core of any privacy protocol and should be designed to be as optimal as possible. In Halo 2, the complexity (i.e. the size) of the circuit is directly correlated to the proof verification time as well as the proof size. Thus, the cost (i.e. blockchain resources) of private transactions is directly determined by the complexity of the arithmetic circuit.

The circuits of all three Zcash protocols - Sprout, Sapling and Orchard - are fundamentally different from each other. This is mainly due to the use of different zk-SNARK proving systems, in which cryptographic "gadgets" - i.e. arithmetic implementations of hash functions or elliptic curve cryptography - have different complexity (i.e. number of constraints).

The Zcash Orchard Shielded Protocol, for example, is based on the Halo 2 Proving System and a PLONKish Arithmetization in which lookup tables can be used. This allows the Sinsemilla hash function, which was developed specifically for this protocol, to be implemented highly efficiently within the circuit. This is crucial for the complexity of the circuit, since for each UTXO that is issued, the valid merkle path must be proven, resulting in a concatenation of multiple Sinsemilla gadgets within the circuit. Since the merkle path accounts for the vast majority of the complexity of the entire circuit, the choice of an efficiently implementable hash function is crucial.

For example, in the protocol evolution from Zcash Sprout to Zcash Sapling, the hash function used in the Merkle tree was changed from Sha256 to Blake2s, since the latter leads to a significantly lower number of constraints in a Groth16 proving system (over the curves Bls12-381/Jubjub) and R1CS arithmetization. There are a number of interesting discussions on this topic by Zcash developers on Github.

The arithmetic circuit is of critical importance to the protocol, as it defines exactly what a valid UTXO transaction is. In the following, we will first roughly explain the arithmetic circuit of the Zcash Orchard Shielded Protocol and then describe the changes that lead to the design of the ZEOS Orchard Shielded Protocol arithmetic circuit.

Notation

The following notation is used to formally express arithmetic circuits and their context.

• $\omega$: The private inputs of an arithmetic circuit
• $x$: The public inputs of an arithmetic circuit
• $C$: An arithmetic circuit $C:(\omega ,x)\to \{0,1\}$
• ${\pi }_{C,\omega ,x}$: A proof for a circuit $C$ created with arguments $(\omega ,x)$

Zcash Action Circuit

A Zcash Orchard transaction is defined as a sequence of one or more actions. The Zcash Orchard circuit defines what a valid action is. It is important to note that in addition to shielded UTXOs, Zcash also has a transparent value pool (i.e. the Zcash protocol also allows for transparent, traceable transactions).

The general idea is as follows: Each action allows the spending of up to one UTXO ($\mathsf{not}{\mathsf{e}}_{\mathsf{old}}$) and the creation of up to one new UTXO ($\mathsf{not}{\mathsf{e}}_{\mathsf{new}}$). To balance the value difference between them there is a balancing value (${\mathsf{v}}_{\mathsf{net}}$).

The equation applies:

$$\mathsf{not}{\mathsf{e}}_{\mathsf{old}}.v=\mathsf{not}{\mathsf{e}}_{\mathsf{new}}.v+{\mathsf{v}}_{\mathsf{net}}$$

where $.v$ refers to the value (i.e. the amount of ZEC) of a UTXO as defined in section 3.2 (p.14) of the Zcash Protocol Specification.

The value ${\mathsf{v}}_{\mathsf{net}}$ thus expresses whether the UTXO transfer of a single Orchard action results in a positive or negative value surplus. Over the entire transaction - i.e. over the sum of all actions - ${\mathsf{v}}_{\mathsf{net}}$ must obviously result in zero. This means that the sum of all inputs of a transaction must be equal to the sum of all outputs.

However, the actual value surplus of an action remains secret - just like the private inputs of the circuit (i.e. the sensitive UTXO data). Instead, only a so-called $\mathsf{ValueCommit}$ of ${\mathsf{v}}_{\mathsf{net}}$ is published, which is specified in section 5.4.8.3 of the Zcash Protocol Specification.

The $\mathsf{ValueCommit}$ is a Pedersen Commitment that has special cryptographic properties such as homomorphic addition. This property allows for the ${\mathsf{v}}_{\mathsf{net}}$ values of all actions of the same transaction to be balanced without having to disclose the actual differences ${\mathsf{v}}_{\mathsf{net}}$ of individual actions publicly: The homomorphically encrypted $\mathsf{ValueCommit}$ of all individual actions can be summed up and eventually balanced with a single transparent value from the transparent value pool (in case the sum is not zero). See section 4.14 of the Zcash Protocol Specification to learn more about the final balancing value of a shielded transaction.

A shielded transaction in Zcash Orchard therefore either generates a transparent output (${\mathsf{v}}_{\mathsf{net}}>0$), or it consumes a transparent input (${\mathsf{v}}_{\mathsf{net}}<0$), or ${\mathsf{v}}_{\mathsf{net}}$ equals zero, in which case it is a fully shielded transaction with no inputs or outputs from the transparent value pool.

The flexibility of this circuit design therefore allows the four different types of actions:

1. transparent → shielded ($\mathsf{not}{\mathsf{e}}_{\mathsf{old}}=0$, resembles a mint).
2. shielded → transparent ($\mathsf{not}{\mathsf{e}}_{\mathsf{new}}=0$, resembles a burn)
3. shielded → shielded (${\mathsf{v}}_{\mathsf{net}}=0$, resembles a shielded transfer)
4. mixed → mixed (either mint + shielded transfer or burn + shielded transfer)

The following schematic shows a highly simplified representation of the Zcash Orchard top level arithmetic circuit, reduced to the essential components. The black inputs are the private inputs of the arithmetic circuit and the blue inputs are the public inputs. Only if all equality gates (==) resolve to true the output of the circuit is $1$, otherwise it is $0$.

The circuit is divided into three areas, which are highlighted in different colors:

Area A contains all the logic regarding $\mathsf{not}{\mathsf{e}}_{\mathsf{old}}$. This is by far the most complex part of the circuit, since the validity of $\mathsf{not}{\mathsf{e}}_{\mathsf{old}}$ as well as the validity of $\text{spend\_auth}$ must be proven here. Specifically, it must be proven that:

1. There exists a sister path $\text{auth\_path}$ to the $\mathsf{NoteCommit}$ of $\mathsf{not}{\mathsf{e}}_{\mathsf{old}}$, which leads to a valid $\text{ROOT}$ of the merkle tree (i.e. $\mathsf{not}{\mathsf{e}}_{\mathsf{old}}$ is a valid UTXO).
2. The address of the UTXO $\mathsf{not}{\mathsf{e}}_{\mathsf{old}}$ can be derived from $\text{spend\_auth}$ (i.e. $\text{spend\_auth}$ is indeed the correct private key to $\mathsf{not}{\mathsf{e}}_{\mathsf{old}}$).
3. The nullifier is valid (i.e. $\text{NF}$ is indeed the nullifier of $\mathsf{not}{\mathsf{e}}_{\mathsf{old}}$).

Area B proves that $\text{CM\_NEW}$ is indeed the correct $\mathsf{NoteCommit}$ to the newly created UTXO $\mathsf{not}{\mathsf{e}}_{\mathsf{new}}$.

Area C proves that $\text{CV\_NET}$ actually represents the correct $\mathsf{ValueCommit}$ (aka Pedersen commitment) of the value surplus ${\mathsf{v}}_{\mathsf{net}}$.

Modifications

However, for the ZEOS Orchard Shielded Protocol, the Zcash Orchard action circuit needs to be slightly adapted. Firstly, because there are no transparent transactions and therefore no transparent value pool in ZEOS. Furthermore, there is not only one, but countless different value pools in ZEOS because of the token diversity in EOSIO/Antelope ecosystems. Finally, there are numerous different fungible tokens as well as NFTs, which have no value pool at all because of their uniqueness.

Therefore the following approach is chosen:

1. $\mathsf{not}{\mathsf{e}}_{\mathsf{old}}$ is renamed to $\mathsf{not}{\mathsf{e}}_{\mathsf{a}}$
2. $\mathsf{not}{\mathsf{e}}_{\mathsf{new}}$ is renamed to $\mathsf{not}{\mathsf{e}}_{\mathsf{b}}$
3. the difference value ${\mathsf{v}}_{\mathsf{net}}$ is converted into a third UTXO $\mathsf{not}{\mathsf{e}}_{\mathsf{c}}$
4. the $\mathsf{ValueCommit}$ of ${\mathsf{v}}_{\mathsf{net}}$ then becomes a $\mathsf{NoteCommit}$ of $\mathsf{not}{\mathsf{e}}_{\mathsf{c}}$

The previous equation of the Zcash Orchard action circuit thus becomes:

$$\mathsf{not}{\mathsf{e}}_{\mathsf{a}}.d1=\mathsf{not}{\mathsf{e}}_{\mathsf{b}}.d1+\mathsf{not}{\mathsf{e}}_{\mathsf{c}}.d1$$

where $.d1$ refers to the value (FT) or ID (NFT) of a UTXO as defined in UTXO Tuple.

Interestingly, the above equation works for both fungible and non-fungible tokens: In case of fungible token transfers, $\mathsf{not}{\mathsf{e}}_{\mathsf{c}}.d1$ represents the change that (normally) goes back into the sender's wallet. In case of NFT transfers, however, $\mathsf{not}{\mathsf{e}}_{\mathsf{c}}.d1$ is necessarily zero, since an NFT cannot be split. But if $\mathsf{not}{\mathsf{e}}_{\mathsf{c}}.d1$ equals zero, it follows from the above equation that $\mathsf{not}{\mathsf{e}}_{\mathsf{a}}.d1=\mathsf{not}{\mathsf{e}}_{\mathsf{b}}.d1$ which corresponds exactly to the desired NFT transfer from $\mathsf{not}{\mathsf{e}}_{\mathsf{a}}$ to $\mathsf{not}{\mathsf{e}}_{\mathsf{b}}$.

In addition to above equations, the following conditions must hold:

$$\mathsf{not}{\mathsf{e}}_{\mathsf{a}}.d2=\mathsf{not}{\mathsf{e}}_{\mathsf{b}}.d2=\mathsf{not}{\mathsf{e}}_{\mathsf{c}}.d2$$ $$\mathsf{not}{\mathsf{e}}_{\mathsf{a}}.sc=\mathsf{not}{\mathsf{e}}_{\mathsf{b}}.sc=\mathsf{not}{\mathsf{e}}_{\mathsf{c}}.sc$$

The equality of all $.d2$ values enforces that either all UTXOs in the circuit must have the same token symbol (FT) or that the upper 64 bits of an ID must match (in case of NFT, but then $\mathsf{not}{\mathsf{e}}_{\mathsf{c}}.d2$ must equal zero). The equality of all $.sc$ values enforces that all UTXOs in the circuit represent tokens issued by the same smart contract.

However, introducing $\mathsf{not}{\mathsf{e}}_{\mathsf{c}}$ and replacing the $\mathsf{ValueCommit}$ with a $\mathsf{NoteCommit}$ comes with the trade-off that value surpluses of multiple actions of the same transaction can no longer be balanced with each other, since a $\mathsf{NoteCommit}$ is no Pedersen commitment and therefore does not have homomorphic properties. This means that in the ZEOS Orchard Shielded Protocol every single action must be balanced out to zero surplus using $\mathsf{not}{\mathsf{e}}_{\mathsf{c}}$, i.e. the inputs of an action ($\mathsf{not}{\mathsf{e}}_{\mathsf{a}}$) must equal the outputs of the same action ($\mathsf{not}{\mathsf{e}}_{\mathsf{b}}+\mathsf{not}{\mathsf{e}}_{\mathsf{c}}$).

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, $C_{zeos}$, 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:

1. $$A=B+C$$

or

2. $$A=C=0$$

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

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

The second configuration is used for minting notes only. The configuration $A=B=0$ effectively disables the circuit parts $A$ and $C$ leaving only part $B$ enabled.

See also:

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

Private Inputs ($\omega$)

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

Note $A$ (action input):

1. $\mathsf{path}$ : 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. $\mathsf{pos}$ : Position of note commitment A inside the merkle tree. Specifically this is the leaf index of note commitment A.
3. ${{\mathsf{g}}_{\mathsf{d}}}_a$ : Address diversify hash of note A. Deterministically derived from a diversifier index (see p. 37 Zcash Protocol Specification).
4. ${\mathsf{p}{\mathsf{k}}_{\mathsf{d}}}_a$ : Address public key of note A. Derived from Incoming Viewing Key and diversify hash (see p. 14 and 37 Zcash Protocol Specification).
5. ${d1}_a$ : Either the value of note A (fungible token) or the (lower 64 bits of the) unique identifier of note A (non-fungible token).
6. ${d2}_a$ : 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. ${\rho }_a$ : 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. ${\psi }_a$ : Additional randomness to derive nullifier of note A (see p. 14 Zcash Protocol Specification)
9. ${\mathsf{rcm}}_a$ : Random commitment trapdoor of note commitment A (see p. 14 and 28 Zcash Protocol Specification)
10. ${\mathsf{cm}}_a$ : Note commit of note A (see p. 28 Zcash Protocol Specification).
11. $\alpha$ : Randomness to derive a spend authorization signature for note A (see p. 55 Zcash Protocol Specification).
12. $\mathsf{ak}$ : Spend Validating Key which is part of the Full Viewing Key components (see p. 36 and 116 Zcash Protocol Specification).
13. $\mathsf{nk}$ : Nullifier Deriving Key which is part of the Full Viewing Key components (see p. 36 and 116 Zcash Protocol Specification).
14. $\mathsf{rivk}$ : 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 $B$ (action output):

15. ${{\mathsf{g}}_{\mathsf{d}}}_b$ : Address diversify hash of note B.
16. ${\mathsf{p}{\mathsf{k}}_{\mathsf{d}}}_b$ : Address public key of note B.
17. ${d1}_b$ : Either the value of note B (fungible token) or the (lower 64 bits of the) unique identifier of note B (non-fungible token).
18. ${d2}_b$ : Either the symbol code of note B (fungible token) or the (upper 64 bits of the) unique identifier of note B (non-fungible token).
19. ${\mathsf{sc}}_b$ : The code of the smart contract issuing notes A, B and C.
20. ${\rho }_b$ : Randomness to derive nullifier of note B (equals nullifier of note A).
21. ${\psi }_b$ : Additional randomness to derive nullifier of note B.
22. ${\mathsf{rcm}}_b$ : Random commitment trapdoor of note commitment B.
23. ${\mathsf{acc}}_b$ : Code of EOS account in which this note is 'burned'.

Note $C$ (action output):

24. ${{\mathsf{g}}_{\mathsf{d}}}_c$ : Address diversify hash of note C.
25. ${\mathsf{p}{\mathsf{k}}_{\mathsf{d}}}_c$ : Address public key of note C.
26. ${d1}_c$ : Value of note C (fungible token only).
27. ${\psi }_c$ : Additional randomness to derive nullifier of note C.
28. ${\mathsf{rcm}}_c$ : Random commitment trapdoor of note commitment C.
29. ${\mathsf{acc}}_c$ : Code of EOS account in which this note is 'burned'.

Public Inputs ($x$)

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

1. $\mathsf{ANCHOR}$ : Merkle tree root of authentication path of note A (see p. 17 to 19 Zcash Protocol Specification).
2. $\mathsf{NF}$ : Nullifier of note A (see p. 56 Zcash Protocol Specification).
3. ${\mathsf{RK}}_X$ : Spend Authority (x component) of ($\alpha$, $\mathsf{ak}$) (see p. 61 Zcash Protocol Specification).
4. ${\mathsf{RK}}_Y$ : Spend Authority (y component).
5. $\mathsf{NFT}$ : Indicates if notes in circuit represent NFTs or fungible tokens.
6. ${\mathsf{B}}_{d1}$ : Exposes value (fungible token) or unique id (non-fungible token) of note B in case of MINT or BURN.
7. ${\mathsf{B}}_{d2}$ : Exposes symbol (fungible token) or unique id (non-fungible token) of note B in case of MINT or BURN.
8. ${\mathsf{B}}_{sc}$ : Exposes smart contract code of note B in case of MINT or BURN.
9. ${\mathsf{C}}_{d1}$ : Exposes value of note C in case of BURNFT2 (fungible tokens only).
10. ${\mathsf{CM}}_B$ : Note commitment of note B.
11. ${\mathsf{CM}}_C$ : Note commitment of note C.
12. ${\mathsf{ACC}}_B$ : Code of EOS account into which note B is 'burned'.
13. ${\mathsf{ACC}}_C$ : Code of EOS account into which note C is 'burned'.

Circuit Internal Signals

The following signals are circuit-internal only.

1. $\mathsf{root}$ : Derived root of merkle path of note A.
2. ${\mathsf{cm}}_a^{\prime }$ : Derived commitment of note A.
3. ${\mathsf{p}{\mathsf{k}}_{\mathsf{d}}}_a^{\prime }$ : Derived address public key of note A.
4. ${\mathsf{rk}}_x$ : Derived spend authority (x component) of note A.
5. ${\mathsf{rk}}_y$ : Derived spend authority (y component) of note A.
6. ${\mathsf{nf}}_a$ : Derived nullifier of note A.
7. ${\mathsf{cm}}_b$ : Derived commitment of note B.
8. ${\mathsf{cm}}_c$ : 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 $A=B+C$ or $A=C=0$' results in the following constraint for the note values ${d1}_a,{d1}_b,{d1}_c$:

1. $$({d1}_a-{d1}_b-{d1}_c)\cdot ({d1}_a+{d1}_c)=0$$

For circuit part A the following constraints must hold:

2. $${d1}_a\cdot (\mathsf{root}-\mathsf{ANCHOR})=0$$
3. $${d1}_a\cdot ({\mathsf{cm}}_a-{\mathsf{cm}}_a^{\prime })=0$$
4. $${d1}_a\cdot ({\mathsf{p}{\mathsf{k}}_{\mathsf{d}}}_a-{\mathsf{p}{\mathsf{k}}_{\mathsf{d}}}_a^{\prime })=0$$
5. $${d1}_a\cdot ({\mathsf{rk}}_x-{\mathsf{RK}}_x)=0$$
6. $${d1}_a\cdot ({\mathsf{rk}}_y-{\mathsf{RK}}_y)=0$$
7. $${d1}_a\cdot ({d2}_a-{d2}_b)=0$$
8. $${d1}_a\cdot ({\mathsf{nf}}_a+{\rho }_b-2\cdot \mathsf{NF})=0$$

For circuit part B the following constraints must hold:

9. $${\mathsf{B}}_{d1}\cdot ({\mathsf{B}}_{d1}-{d1}_b)=0$$
10. $${\mathsf{B}}_{d1}\cdot ({\mathsf{B}}_{d2}-{d2}_b)=0$$
11. $${\mathsf{B}}_{d1}\cdot ({\mathsf{B}}_{sc}-{\mathsf{sc}}_b)=0$$
12. $${\mathsf{CM}}_B\cdot ({\mathsf{CM}}_B-{\mathsf{cm}}_b)=0$$
13. $${\mathsf{ACC}}_B-{\mathsf{acc}}_b=0$$

For circuit part C the following constraints must hold:

14. $$\mathsf{NFT}\cdot {d1}_c=0$$
15. $${\mathsf{C}}_{d1}\cdot ({\mathsf{C}}_{d1}-{d1}_c)=0$$
16. $${\mathsf{CM}}_C\cdot ({\mathsf{CM}}_C-{\mathsf{cm}}_c)=0$$
17. $${\mathsf{ACC}}_C-{\mathsf{acc}}_c=0$$

Valid Circuit Configurations

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

$\begin{array}{cccccccccccccc}\mathsf{ZAction}& \mathsf{ANCHOR}& \mathsf{NF}& \mathsf{R}{\mathsf{K}}_{\mathsf{x}}& \mathsf{R}{\mathsf{K}}_{\mathsf{y}}& \mathsf{NFT}& {\mathsf{B}}_{d1}& {\mathsf{B}}_{d2}& {\mathsf{B}}_{sc}& {\mathsf{C}}_{d1}& {\mathsf{CM}}_B& {\mathsf{CM}}_C& {\mathsf{ACC}}_B& {\mathsf{ACC}}_C\\ MINTFT& 0& 0& 0& 0& 0& {d1}_b& {d2}_b& {\mathsf{sc}}_b& 0& {\mathsf{cm}}_b& 0& 0& 0\\ MINTNFT/BURNAT& 0& 0& 0& 0& 1& {d1}_b& {d2}_b& {\mathsf{sc}}_b& 0& {\mathsf{cm}}_b& 0& 0& 0\\ TRANSFERFT& \mathsf{root}& {\mathsf{nf}}_a& {\mathsf{rk}}_x& {\mathsf{rk}}_y& 0& 0& 0& 0& 0& {\mathsf{cm}}_b& {\mathsf{cm}}_c& 0& 0\\ TRANSFERNFT& \mathsf{root}& {\mathsf{nf}}_a& {\mathsf{rk}}_x& {\mathsf{rk}}_y& 1& 0& 0& 0& 0& {\mathsf{cm}}_b& 0& 0& 0\\ BURNFT& \mathsf{root}& {\mathsf{nf}}_a& {\mathsf{rk}}_x& {\mathsf{rk}}_y& 0& {d1}_b& {d2}_b& {\mathsf{sc}}_b& 0& 0& {\mathsf{cm}}_c& {\mathsf{acc}}_b& 0\\ BURNFT2& \mathsf{root}& {\mathsf{nf}}_a& {\mathsf{rk}}_x& {\mathsf{rk}}_y& 0& {d1}_b& {d2}_b& {\mathsf{sc}}_b& {d1}_c& 0& 0& {\mathsf{acc}}_b& {\mathsf{acc}}_c\\ BURNNFT& \mathsf{root}& {\mathsf{nf}}_a& {\mathsf{rk}}_x& {\mathsf{rk}}_y& 1& {d1}_b& {d2}_b& {\mathsf{sc}}_b& 0& 0& 0& {\mathsf{acc}}_b& 0\end{array}$

MINTFT

$\begin{array}{ccccccccccccc}\mathsf{ANCHOR}& \mathsf{NF}& \mathsf{R}{\mathsf{K}}_{\mathsf{x}}& \mathsf{R}{\mathsf{K}}_{\mathsf{y}}& \mathsf{NFT}& {\mathsf{B}}_{d1}& {\mathsf{B}}_{d2}& {\mathsf{B}}_{sc}& {\mathsf{C}}_{d1}& \mathsf{C}{\mathsf{M}}_{\mathsf{B}}& {\mathsf{CM}}_C& {\mathsf{ACC}}_B& {\mathsf{ACC}}_C\\ 0& 0& 0& 0& 0& {d1}_b& {d2}_b& {\mathsf{sc}}_b& 0& {\mathsf{cm}}_b& 0& 0& 0\end{array}$

Given: $\mathsf{ANCHOR}=\mathsf{NF}=\mathsf{R}{\mathsf{K}}_{\mathsf{x}}=\mathsf{R}{\mathsf{K}}_{\mathsf{y}}=0$
$\Rightarrow {d1}_a=0$ because of internal signals (1), (4), (5), (6) and constraints (2), (5), (6) and (8)

Given: ${\mathsf{CM}}_B={\mathsf{cm}}_b$
$\Rightarrow {d1}_b\ne 0$ because of internal signal (7)

Given: ${d1}_a=0,{d1}_b\ne 0$
$\Rightarrow {d1}_c=0$ because of constraint (1)

Given: ${\mathsf{ACC}}_B=0$
$\Rightarrow {\mathsf{acc}}_b=0$ because of constraint (13)

Given: ${\mathsf{ACC}}_C=0$
$\Rightarrow {\mathsf{acc}}_c=0$ because of constraint (17)

MINTNFT/BURNAT

Note: The actions MINTNFT and BURNAT share the exact same circuit configuration. $\begin{array}{ccccccccccccc}\mathsf{ANCHOR}& \mathsf{NF}& \mathsf{R}{\mathsf{K}}_{\mathsf{x}}& \mathsf{R}{\mathsf{K}}_{\mathsf{y}}& \mathsf{NFT}& {\mathsf{B}}_{d1}& {\mathsf{B}}_{d2}& {\mathsf{B}}_{sc}& {\mathsf{C}}_{d1}& \mathsf{C}{\mathsf{M}}_{\mathsf{B}}& {\mathsf{CM}}_C& {\mathsf{ACC}}_B& {\mathsf{ACC}}_C\\ 0& 0& 0& 0& 1& {d1}_b& {d2}_b& {\mathsf{sc}}_b& 0& {\mathsf{cm}}_b& 0& 0& 0\end{array}$

Given: $\mathsf{ANCHOR}=\mathsf{NF}=\mathsf{R}{\mathsf{K}}_{\mathsf{x}}=\mathsf{R}{\mathsf{K}}_{\mathsf{y}}=0$
$\Rightarrow {d1}_a=0$ because of internal signals (1), (4), (5), (6) and constraints (2), (5), (6) and (8)

Given: ${\mathsf{CM}}_B={\mathsf{cm}}_b$
$\Rightarrow {d1}_b\ne 0$ because of internal signal (7)

Given: $\mathsf{NFT}=1,{d1}_a=0,{d1}_b\ne 0$
$\Rightarrow {d1}_c=0$ because of constraints (1) and (14)

Given: ${\mathsf{ACC}}_B=0$
$\Rightarrow {\mathsf{acc}}_b=0$ because of constraint (13)

Given: ${\mathsf{ACC}}_C=0$
$\Rightarrow {\mathsf{acc}}_c=0$ because of constraint (17)

TRANSFERFT

$\begin{array}{ccccccccccccc}\mathsf{ANCHOR}& \mathsf{NF}& \mathsf{R}{\mathsf{K}}_{\mathsf{x}}& \mathsf{R}{\mathsf{K}}_{\mathsf{y}}& \mathsf{NFT}& {\mathsf{B}}_{d1}& {\mathsf{B}}_{d2}& {\mathsf{B}}_{sc}& {\mathsf{C}}_{d1}& \mathsf{C}{\mathsf{M}}_{\mathsf{B}}& {\mathsf{CM}}_C& {\mathsf{ACC}}_B& {\mathsf{ACC}}_C\\ \mathsf{root}& {\mathsf{nf}}_a& {\mathsf{rk}}_x& {\mathsf{rk}}_y& 0& 0& 0& 0& 0& {\mathsf{cm}}_b& {\mathsf{cm}}_c& 0& 0\end{array}$

Given: $\mathsf{ANCHOR}=\mathsf{root},\mathsf{NF}={\mathsf{nf}}_a,{\mathsf{RK}}_x={\mathsf{rk}}_x,{\mathsf{RK}}_y={\mathsf{rk}}_y$
$\Rightarrow {d1}_a\ne 0$ because of internal signals (1), (4), (5), (6) and constraints (2), (5), (6) and (8)

Given: ${d1}_a\ne 0$
$\Rightarrow {d1}_a={d1}_b+{d1}_c$ because of constraint (1)
$\Rightarrow {d2}_a={d2}_b$ because of constraint (7)
$\Rightarrow {\rho }_b={\mathsf{nf}}_a$ because of constraint (8)

Given: ${\mathsf{ACC}}_B=0$
$\Rightarrow {\mathsf{acc}}_b=0$ because of constraint (13)

Given: ${\mathsf{ACC}}_C=0$
$\Rightarrow {\mathsf{acc}}_c=0$ because of constraint (17)

TRANSFERNFT

$\begin{array}{ccccccccccccc}\mathsf{ANCHOR}& \mathsf{NF}& \mathsf{R}{\mathsf{K}}_{\mathsf{x}}& \mathsf{R}{\mathsf{K}}_{\mathsf{y}}& \mathsf{NFT}& {\mathsf{B}}_{d1}& {\mathsf{B}}_{d2}& {\mathsf{B}}_{sc}& {\mathsf{C}}_{d1}& \mathsf{C}{\mathsf{M}}_{\mathsf{B}}& {\mathsf{CM}}_C& {\mathsf{ACC}}_B& {\mathsf{ACC}}_C\\ \mathsf{root}& {\mathsf{nf}}_a& {\mathsf{rk}}_x& {\mathsf{rk}}_y& 1& 0& 0& 0& 0& {\mathsf{cm}}_b& 0& 0& 0\end{array}$

Given: $\mathsf{ANCHOR}=\mathsf{root},\mathsf{NF}={\mathsf{nf}}_a,{\mathsf{RK}}_x={\mathsf{rk}}_x,{\mathsf{RK}}_y={\mathsf{rk}}_y$
$\Rightarrow {d1}_a\ne 0$ because of internal signals (1), (4), (5), (6) and constraints (2), (5), (6) and (8)

Given: $\mathsf{NFT}=1$
$\Rightarrow {d1}_c=0$ because of constraint (14)

Given: ${d1}_a\ne 0,{d1}_c=0$
$\Rightarrow {d1}_a={d1}_b$ because of constraint (1)

Given: ${d1}_a\ne 0$
$\Rightarrow {d2}_a={d2}_b$ because of constraint (7)
$\Rightarrow {\rho }_b={\mathsf{nf}}_a$ because of constraint (8)

Given: ${\mathsf{ACC}}_B=0$
$\Rightarrow {\mathsf{acc}}_b=0$ because of constraint (13)

Given: ${\mathsf{ACC}}_C=0$
$\Rightarrow {\mathsf{acc}}_c=0$ because of constraint (17)

BURNFT

$\begin{array}{ccccccccccccc}\mathsf{ANCHOR}& \mathsf{NF}& \mathsf{R}{\mathsf{K}}_{\mathsf{x}}& \mathsf{R}{\mathsf{K}}_{\mathsf{y}}& \mathsf{NFT}& {\mathsf{B}}_{d1}& {\mathsf{B}}_{d2}& {\mathsf{B}}_{sc}& {\mathsf{C}}_{d1}& \mathsf{C}{\mathsf{M}}_{\mathsf{B}}& {\mathsf{CM}}_C& {\mathsf{ACC}}_B& {\mathsf{ACC}}_C\\ \mathsf{root}& {\mathsf{nf}}_a& {\mathsf{rk}}_x& {\mathsf{rk}}_y& 0& {d1}_b& {d2}_b& {\mathsf{sc}}_b& 0& 0& {\mathsf{cm}}_c& {\mathsf{acc}}_b& 0\end{array}$

Given: $\mathsf{ANCHOR}=\mathsf{root},\mathsf{NF}={\mathsf{nf}}_a,{\mathsf{RK}}_x={\mathsf{rk}}_x,{\mathsf{RK}}_y={\mathsf{rk}}_y$
$\Rightarrow {d1}_a\ne 0$ because of internal signals (1), (4), (5), (6) and constraints (2), (5), (6) and (8)

Given: ${d1}_a\ne 0$
$\Rightarrow {d1}_a={d1}_b+{d1}_c$ because of constraint (1)
$\Rightarrow {d2}_a={d2}_b$ because of constraint (7)
$\Rightarrow {\rho }_b={\mathsf{nf}}_a$ because of constraint (8)

Given: ${\mathsf{ACC}}_C=0$
$\Rightarrow {\mathsf{acc}}_c=0$ because of constraint (17)

BURNFT2

$\begin{array}{ccccccccccccc}\mathsf{ANCHOR}& \mathsf{NF}& \mathsf{R}{\mathsf{K}}_{\mathsf{x}}& \mathsf{R}{\mathsf{K}}_{\mathsf{y}}& \mathsf{NFT}& {\mathsf{B}}_{d1}& {\mathsf{B}}_{d2}& {\mathsf{B}}_{sc}& {\mathsf{C}}_{d1}& \mathsf{C}{\mathsf{M}}_{\mathsf{B}}& {\mathsf{CM}}_C& {\mathsf{ACC}}_B& {\mathsf{ACC}}_C\\ \mathsf{root}& {\mathsf{nf}}_a& {\mathsf{rk}}_x& {\mathsf{rk}}_y& 0& {d1}_b& {d2}_b& {\mathsf{sc}}_b& {d1}_c& 0& 0& {\mathsf{acc}}_b& {\mathsf{acc}}_c\end{array}$

Given: $\mathsf{ANCHOR}=\mathsf{root},\mathsf{NF}={\mathsf{nf}}_a,{\mathsf{RK}}_x={\mathsf{rk}}_x,{\mathsf{RK}}_y={\mathsf{rk}}_y$
$\Rightarrow {d1}_a\ne 0$ because of internal signals (1), (4), (5), (6) and constraints (2), (5), (6) and (8)

Given: ${d1}_a\ne 0$
$\Rightarrow {d1}_a={d1}_b+{d1}_c$ because of constraint (1)
$\Rightarrow {d2}_a={d2}_b$ because of constraint (7)
$\Rightarrow {\rho }_b={\mathsf{nf}}_a$ because of constraint (8)

BURNNFT

$\begin{array}{ccccccccccccc}\mathsf{ANCHOR}& \mathsf{NF}& \mathsf{R}{\mathsf{K}}_{\mathsf{x}}& \mathsf{R}{\mathsf{K}}_{\mathsf{y}}& \mathsf{NFT}& {\mathsf{B}}_{d1}& {\mathsf{B}}_{d2}& {\mathsf{B}}_{sc}& {\mathsf{C}}_{d1}& \mathsf{C}{\mathsf{M}}_{\mathsf{B}}& {\mathsf{CM}}_C& {\mathsf{ACC}}_B& {\mathsf{ACC}}_C\\ \mathsf{root}& {\mathsf{nf}}_a& {\mathsf{rk}}_x& {\mathsf{rk}}_y& 1& {d1}_b& {d2}_b& {\mathsf{sc}}_b& 0& 0& 0& {\mathsf{acc}}_b& 0\end{array}$

Given: $\mathsf{ANCHOR}=\mathsf{root},\mathsf{NF}={\mathsf{nf}}_a,{\mathsf{RK}}_x={\mathsf{rk}}_x,{\mathsf{RK}}_y={\mathsf{rk}}_y$
$\Rightarrow {d1}_a\ne 0$ because of internal signals (1), (4), (5), (6) and constraints (2), (5), (6) and (8)

Given: $\mathsf{NFT}=1$
$\Rightarrow {d1}_c=0$ because of constraint (14)

Given: ${d1}_a\ne 0,{d1}_c=0$
$\Rightarrow {d1}_a={d1}_b$ because of constraint (1)

Given ${d1}_a\ne 0$
$\Rightarrow {d2}_a={d2}_b$ because of constraint (7)
$\Rightarrow {\rho }_b={\mathsf{nf}}_a$ because of constraint (8)

Given: ${\mathsf{ACC}}_C=0$
$\Rightarrow {\mathsf{acc}}_c=0$ because of constraint (17)

NoteCommit Chip

Besides the changes in the top level design, the $\mathsf{NoteCommit}$ chip has to be adapted to the new UTXO tuple. However, these adaptations are not trivial.

The Sinsemilla hash function operates on multiples of 10 bits of the input message. However, since this is an implementation within an arithmetic circuit (and not an integrated circuit) there are no bits and bytes, only field elements (aka large numbers) as input signals. Thus, the various elements of the UTXO tuple must first be decomposed so that they can be concatenated into chunks of 10 bits and the message parts finally digested as 10 bit chunks. This requires canonicity checks for the value ranges of all message parts.

Compare the original version of this chip from the Zcash Orchard Shielded Protocol.

Message decomposition

$\mathsf{SinsemillaCommit}$ is used in the $\mathsf{NoteCommit}$ function. The input to $\mathsf{SinsemillaCommit}$ is:

$$\mathsf{g}{\star }_{\mathsf{d}}||\mathsf{pk}{\star }_{\mathsf{d}}||{I2LEBSP}_{64}(d1)||{I2LEBSP}_{{\ell }_{\mathsf{base}}^{\mathsf{Orchard}}}(\rho )||{I2LEBSP}_{{\ell }_{\mathsf{base}}^{\mathsf{Orchard}}}(\psi )||{I2LEBSP}_{64}(d2)||{I2LEBSP}_1(\mathsf{nft})||{I2LEBSP}_{64}(\mathsf{sc}),$$

where:

• $\mathsf{g}{\star }_{\mathsf{d}},\mathsf{pk}{\star }_{\mathsf{d}}$ are representations of Pallas curve points, with $255$ bits used for the $x$-coordinate and $1$ bit used for the $y$-coordinate.
• $\rho ,\psi$ are Pallas base field elements.
• $d1$ is a $64$-bit value.
• ${\ell }_{\mathsf{base}}^{\mathsf{Orchard}}=255.$
• $d2$ is a $64$-bit value.
• $\mathsf{nft}$ is a $1$-bit value.
• $\mathsf{sc}$ is a $64$-bit value.

Sinsemilla operates on multiples of 10 bits, so we start by decomposing the message into chunks:

$$\begin{array}{rl}\mathsf{g}{\star }_{\mathsf{d}}& =a||b_0||b_1||b_2\\ & =(\text{bits 0..=249 of }x({\mathsf{g}}_{\mathsf{d}}))||(\text{bits 250..=253 of }x({\mathsf{g}}_{\mathsf{d}}))||(\text{bit 254 of }x({\mathsf{g}}_{\mathsf{d}}))||(\tilde{y}\text{ bit of }{\mathsf{g}}_{\mathsf{d}})\\ \mathsf{pk}{\star }_{\mathsf{d}}& =b_3||c||d_0||d_1\\ & =(\text{bits 0..=3 of }x(\mathsf{p}{\mathsf{k}}_{\mathsf{d}}))||(\text{bits 4..=253 of }x(\mathsf{p}{\mathsf{k}}_{\mathsf{d}}))||(\text{bit 254 of }x(\mathsf{p}{\mathsf{k}}_{\mathsf{d}}))||(\tilde{y}\text{ bit of }\mathsf{p}{\mathsf{k}}_{\mathsf{d}})\\ {I2LEBSP}_{64}(d1)& =d_2||d_3||e_0\\ & =(\text{bits 0..=7 of }d1)||(\text{bits 8..=57 of }d1)||(\text{bits 58..=63 of }d1)\\ {I2LEBSP}_{{\ell }_{\mathsf{base}}^{\mathsf{Orchard}}}(\rho )& =e_1||f||g_0\\ & =(\text{bits 0..=3 of }\rho )||(\text{bits 4..=253 of }\rho )||(\text{bit 254 of }\rho )\\ {I2LEBSP}_{{\ell }_{\mathsf{base}}^{\mathsf{Orchard}}}(\psi )& =g_1||g_2||h_0||h_1\\ & =(\text{bits 0..=8 of }\psi )||(\text{bits 9..=248 of }\psi )||(\text{bits 249..=253 of }\psi )||(\text{bit 254 of }\psi )\\ {I2LEBSP}_{64}(d2)& =h_2||h_3\\ & =(\text{bits 0..=3 of }d2)||(\text{bits 4..=63 of }d2)\\ {I2LEBSP}_1(\mathsf{nft})& =i_0\\ & =(\text{bit 0 of }\mathsf{nft})\\ {I2LEBSP}_{64}(\mathsf{sc})& =i_1||i_2||j_0||j_1\\ & =(\text{bits 0..=8 of }\mathsf{sc})||(\text{bits 9..=58 of }\mathsf{sc})||(\text{bits 59..=63 of }\mathsf{sc})\end{array}$$

Then we recompose the chunks into message pieces:

$$\begin{array}{cl}\text{Length (bits)}& \text{Piece}\\ 250& a\\ 10& b=b_0||b_1||b_2||b_3\\ 250& c\\ 60& d=d_0||d_1||d_2||d_3\\ 10& e=e_0||e_1\\ 250& f\\ 250& g=g_0||g_1||g_2\\ 70& h=h_0||h_1||h_2||h_3\\ 60& i=i_0||i_1||i_2\\ 10& j=j_0||j_1\end{array}$$

where $j_1$ is 5 zero bits (corresponding to the padding applied by the Sinsemilla $\mathsf{pad}$ function).

Each message piece is constrained by $\mathsf{SinsemillaHash}$ to its stated length. Additionally:

• ${\mathsf{g}}_{\mathsf{d}}$ and $\mathsf{p}{\mathsf{k}}_{\mathsf{d}}$ are witnessed and checked to be valid elliptic curve points.
• $d1$ is witnessed as a field element, but its decomposition is sufficient to constrain it to be a 64-bit value.
• $d2$ is witnessed as a field element, but its decomposition is sufficient to constrain it to be a 64-bit value.
• $\mathsf{sc}$ is witnessed as a field element, but its decomposition is sufficient to constrain it to be a 64-bit value.
• $\mathsf{nft}$ is witnessed as a field element, but its decomposition is sufficient to constrain it to be a 1-bit value.
• $\rho$ and $\psi$ are witnessed as field elements, so we know they are canonical.

However, we need additional constraints to enforce that:

• The chunks are the correct bit lengths (or else they could overlap in the decompositions and allow the prover to witness an arbitrary $\mathsf{SinsemillaCommit}$ message).
• The chunks contain the canonical decompositions of ${\mathsf{g}}_{\mathsf{d}}$, $\mathsf{p}{\mathsf{k}}_{\mathsf{d}}$, $\rho$, and $\psi$ (or else the prover could witness multiple equivalent inputs to $\mathsf{SinsemillaCommit}$).

Some of these constraints are implemented with a reusable circuit gadget, $\text{short\_lookup\_range\_check}()$. We define custom gates for the remainder. Since these gates use simple boolean selectors activated on different rows, their selectors are eligible for combining, reducing the overall proof size.

Message piece decomposition

We check the decomposition of each message piece in its own region. There is no need to check the whole pieces:

• $a$ ($250$ bits) is witnessed and constrained outside the gate;
• $c$ ($250$ bits) is witnessed and constrained outside the gate;
• $f$ ($250$ bits) is witnessed and constrained outside the gate;

The following helper gates are defined:

• $\text{bool\_check}(x)=x\cdot (1-x)$.
• $\text{short\_lookup\_range\_check}()$ is a short lookup range check.

$b=b_0||b_1||b_2||b_3$

$b$ has been constrained to be $10$ bits by the Sinsemilla hash.

Region layout

$$\begin{array}{cccc}{A}_6& A_7& A_8& q_{\mathsf{NoteCommit},b}\\ b& b_0& b_1& 1\\ & b_2& b_3& 0\end{array}$$

Constraints

$$\begin{array}{cl}\text{Degree}& \text{Constraint}\\ 3& q_{\mathsf{NoteCommit},b}\cdot \text{bool\_check}(b_1)=0\\ 3& q_{\mathsf{NoteCommit},b}\cdot \text{bool\_check}(b_2)=0\\ 2& q_{\mathsf{NoteCommit},b}\cdot (b-(b_0+b_1\cdot 2^4+b_2\cdot 2^5+b_3\cdot 2^6))=0\end{array}$$

Outside this gate, we have constrained:

• $\text{short\_lookup\_range\_check}(b_0,4)$
• $\text{short\_lookup\_range\_check}(b_3,4)$

$d=d_0||d_1||d_2||d_3$

$d$ has been constrained to be $60$ bits by the $\mathsf{SinsemillaHash}$.

Region layout

$$\begin{array}{cccc}{A}_6& A_7& A_8& q_{\mathsf{NoteCommit},d}\\ d& d_0& d_1& 1\\ & d_2& d_3& 0\end{array}$$

Constraints

$$\begin{array}{cl}\text{Degree}& \text{Constraint}\\ 3& q_{\mathsf{NoteCommit},d}\cdot \text{bool\_check}(d_0)=0\\ 3& q_{\mathsf{NoteCommit},d}\cdot \text{bool\_check}(d_1)=0\\ 2& q_{\mathsf{NoteCommit},d}\cdot (d-(d_0+d_1\cdot 2+d_2\cdot 2^2+d_3\cdot 2^{10}))=0\end{array}$$

Outside this gate, we have constrained:

• $\text{short\_lookup\_range\_check}(d_2,8)$
• $d_3$ is equality-constrained to $z_{d,1}$, where the latter is the index-1 running sum output of $\mathsf{SinsemillaHash}(d)$, constrained by the hash to be $50$ bits.

$e=e_0||e_1$

$e$ has been constrained to be $10$ bits by the $\mathsf{SinsemillaHash}$.

Region layout

$$\begin{array}{cccc}{A}_6& A_7& A_8& q_{\mathsf{NoteCommit},e}\\ e& e_0& e_1& 1\end{array}$$

Constraints

$$\begin{array}{cl}\text{Degree}& \text{Constraint}\\ 2& q_{\mathsf{NoteCommit},e}\cdot (e-(e_0+e_1\cdot 2^6))=0\end{array}$$

Outside this gate, we have constrained:

• $\text{short\_lookup\_range\_check}(e_0,6)$
• $\text{short\_lookup\_range\_check}(e_1,4)$

$g=g_0||g_1||g_2$

$g$ has been constrained to be $250$ bits by the $\mathsf{SinsemillaHash}$.

Region layout

$$\begin{array}{ccc}{A}_6& A_7& q_{\mathsf{NoteCommit},g}\\ g& g_0& 1\\ g_1& g_2& 0\end{array}$$

Constraints

$$\begin{array}{cl}\text{Degree}& \text{Constraint}\\ 3& q_{\mathsf{NoteCommit},g}\cdot \text{bool\_check}(g_0)=0\\ 2& q_{\mathsf{NoteCommit},g}\cdot (g-(g_0+g_1\cdot 2+g_2\cdot 2^{10}))=0\end{array}$$

Outside this gate, we have constrained:

• $\text{short\_lookup\_range\_check}(g_1,9)$
• $g_2$ is equality-constrained to $z_{g,1}$, where the latter is the index-1 running sum output of $\mathsf{SinsemillaHash}(g)$, constrained by the hash to be 240 bits.

$h=h_0||h_1||h_2||h_3$

$h$ has been constrained to be $70$ bits by the $\mathsf{SinsemillaHash}$.

Region layout

$$\begin{array}{cccc}{A}_6& A_7& A_8& q_{\mathsf{NoteCommit},h}\\ h& h_0& h_1& 1\\ & h_2& h_3& 0\end{array}$$

Constraints

$$\begin{array}{cl}\text{Degree}& \text{Constraint}\\ 3& q_{\mathsf{NoteCommit},h}\cdot \text{bool\_check}(h_1)=0\\ 2& q_{\mathsf{NoteCommit},h}\cdot (h-(h_0+h_1\cdot 2^5+h_2\cdot 2^6+h_3\cdot 2^{10}))=0\end{array}$$

Outside this gate, we have constrained:

• $\text{short\_lookup\_range\_check}(h_0,5)$
• $\text{short\_lookup\_range\_check}(h_2,4)$
• $\text{short\_lookup\_range\_check}(h_3,60)$
• $h_3$ is equality-constrained to $z_{h,1}$, where the latter is the index-1 running sum output of $\mathsf{SinsemillaHash}(h)$, constrained by the hash to be 60 bits.

$i=i_0||i_1||i_2$

$i$ has been constrained to be $60$ bits by the $\mathsf{SinsemillaHash}$.

Region layout

$$\begin{array}{ccc}{A}_6& A_7& q_{\mathsf{NoteCommit},i}\\ i& i_0& 1\\ i_1& i_2& 0\end{array}$$

Constraints

$$\begin{array}{cl}\text{Degree}& \text{Constraint}\\ 3& q_{\mathsf{NoteCommit},i}\cdot \text{bool\_check}(i_0)=0\\ 2& q_{\mathsf{NoteCommit},i}\cdot (i-(i_0+i_1\cdot 2+i_2\cdot 2^{10}))=0\end{array}$$

Outside this gate, we have constrained:

• $\text{short\_lookup\_range\_check}(i_1,9)$
• $\text{short\_lookup\_range\_check}(i_2,50)$
• $i_2$ is equality-constrained to $z_{i,1}$, where the latter is the index-1 running sum output of $\mathsf{SinsemillaHash}(i)$, constrained by the hash to be 50 bits.

$j=j_0||j_1$

$j$ has been constrained to be $10$ bits by the $\mathsf{SinsemillaHash}$.

Region layout

$$\begin{array}{ccc}{A}_6& A_7& q_{\mathsf{NoteCommit},i}\\ j& j_0& 1\end{array}$$

Constraints

$$\begin{array}{cl}\text{Degree}& \text{Constraint}\\ 2& q_{\mathsf{NoteCommit},j}\cdot (j-j_0)=0\end{array}$$

Outside this gate, we have constrained:

• $\text{short\_lookup\_range\_check}(j_0,5)$

Field element checks

All message pieces and subpieces have been range-constrained by the earlier decomposition gates. They are now used to:

• constrain each field element ${I2LEBSP}_{{\ell }_{\mathsf{base}}^{\mathsf{Orchard}}}(x({\mathsf{g}}_{\mathsf{d}}))$, ${I2LEBSP}_{{\ell }_{\mathsf{base}}^{\mathsf{Orchard}}}(x(\mathsf{p}{\mathsf{k}}_{\mathsf{d}}))$, ${I2LEBSP}_{{\ell }_{\mathsf{base}}^{\mathsf{Orchard}}}(\rho )$, and ${I2LEBSP}_{{\ell }_{\mathsf{base}}^{\mathsf{Orchard}}}(\psi )$ to be 255-bit values, with top bits $b_1$, $d_0$, $g_0$, and $h_1$ respectively.
• constrain $$\begin{array}{rl}{I2LEBSP}_{{\ell }_{\mathsf{base}}^{\mathsf{Orchard}}}(x({\mathsf{g}}_{\mathsf{d}}))& =x({\mathsf{g}}_{\mathsf{d}})(\mathrm{mod}{q}_{\mathbb{P}})\\ {I2LEBSP}_{{\ell }_{\mathsf{base}}^{\mathsf{Orchard}}}(x(\mathsf{p}{\mathsf{k}}_{\mathsf{d}}))& =x(\mathsf{p}{\mathsf{k}}_{\mathsf{d}})(\mathrm{mod}{q}_{\mathbb{P}})\\ {I2LEBSP}_{{\ell }_{\mathsf{base}}^{\mathsf{Orchard}}}(\rho )& =\rho (\mathrm{mod}{q}_{\mathbb{P}})\\ {I2LEBSP}_{{\ell }_{\mathsf{base}}^{\mathsf{Orchard}}}(\psi )& =\psi (\mathrm{mod}{q}_{\mathbb{P}})\end{array}$$ where $q_{\mathbb{P}}$ is the Pallas base field modulus.
• check that these are indeed canonically-encoded field elements, i.e. $$\begin{array}{rl}{I2LEBSP}_{{\ell }_{\mathsf{base}}^{\mathsf{Orchard}}}(x({\mathsf{g}}_{\mathsf{d}}))& <q_{\mathbb{P}}\\ {I2LEBSP}_{{\ell }_{\mathsf{base}}^{\mathsf{Orchard}}}(x(\mathsf{p}{\mathsf{k}}_{\mathsf{d}}))& <q_{\mathbb{P}}\\ {I2LEBSP}_{{\ell }_{\mathsf{base}}^{\mathsf{Orchard}}}(\rho )& <q_{\mathbb{P}}\\ {I2LEBSP}_{{\ell }_{\mathsf{base}}^{\mathsf{Orchard}}}(\psi )& <q_{\mathbb{P}}\end{array}$$

The Pallas base field modulus has the form $q_{\mathbb{P}}=2^{254}+t_{\mathbb{P}}$, where $$t_{\mathbb{P}}=0x224698fc094cf91b992d30ed00000001$$ is 126 bits. We therefore know that if the top bit is not set, then the remaining bits will always comprise a canonical encoding of a field element. Thus the canonicity checks below are enforced if and only if the corresponding top bit is set to 1.

In the constraints below we use a base-$2^{10}$ variant of the method used in libsnark (originally from [SVPBABW2012, Appendix C.1]) for range constraints $0\le x<t$:

• Let $t^{\prime }$ be the smallest power of $2^{10}$ greater than $t$.
• Enforce $0\le x<t^{\prime }$.
• Let $x^{\prime }=x+t^{\prime }-t$.
• Enforce $0\le x^{\prime }<t^{\prime }$.

$x({\mathsf{g}}_{\mathsf{d}})$ with $b_1=1⟹x({\mathsf{g}}_{\mathsf{d}})\ge 2^{254}$

Recall that $x({\mathsf{g}}_{\mathsf{d}})=a+2^{250}\cdot b_0+2^{254}\cdot b_1$. When the top bit $b_1$ is set, we check that $x({\mathsf{g}}_{\mathsf{d}}{)}_{\mathrm{0..}=253}<t_{\mathbb{P}}$:

1. $b_1=1⟹b_0=0.$

   Since $b_1=1⟹x({\mathsf{g}}_{\mathsf{d}}{)}_{\mathrm{0..}=253}<t_{\mathbb{P}}<2^{126},$ we know that $x({\mathsf{g}}_{\mathsf{d}}{)}_{\mathrm{126..}=253}=0,$ and in particular $$b_0:=x({\mathsf{g}}_{\mathsf{d}}{)}_{\mathrm{250..}=253}=0.$$

2. $b_1=1⟹0\le a<t_{\mathbb{P}}.$

   To check that $a<t_{\mathbb{P}}$, we use two constraints:

   a) $0\le a<2^{130}$. This is expressed in the custom gate as $$b_1\cdot z_{a,13}=0,$$ where $z_{a,13}$ is the index-13 running sum output by $\mathsf{SinsemillaHash}(a).$

   b) $0\le a+2^{130}-t_{\mathbb{P}}<2^{130}$. To check this, we decompose $a^{\prime }=a+2^{130}-t_{\mathbb{P}}$ into thirteen 10-bit words (little-endian) using a running sum $z_{a^{\prime }}$, looking up each word in a $10$-bit lookup table. We then enforce in the custom gate that $$b_1\cdot z_{a^{\prime },13}=0.$$

Region layout

$$\begin{array}{ccccc}{A}_6& A_7& A_8& A_9& q_{\mathsf{NoteCommit},x({\mathsf{g}}_{\mathsf{d}})}\\ x({\mathsf{g}}_{\mathsf{d}})& b_0& a& z_{a,13}& 1\\ & b_1& a^{\prime }& z_{a^{\prime },13}& 0\end{array}$$

Constraints

$$\begin{array}{cl}\text{Degree}& \text{Constraint}\\ 2& q_{\mathsf{NoteCommit},x({\mathsf{g}}_{\mathsf{d}})}\cdot (a+b_0\cdot 2^{250}+b_1\cdot 2^{254}-x({\mathsf{g}}_{\mathsf{d}}))=0\\ 3& q_{\mathsf{NoteCommit},x({\mathsf{g}}_{\mathsf{d}})}\cdot b_1\cdot b_0=0\\ 3& q_{\mathsf{NoteCommit},x({\mathsf{g}}_{\mathsf{d}})}\cdot b_1\cdot z_{a,13}=0\\ 2& q_{\mathsf{NoteCommit},x({\mathsf{g}}_{\mathsf{d}})}\cdot (a+2^{130}-t_{\mathbb{P}}-a^{\prime })=0\\ 3& q_{\mathsf{NoteCommit},x({\mathsf{g}}_{\mathsf{d}})}\cdot b_1\cdot z_{a^{\prime },13}=0\end{array}$$

$x(\mathsf{p}{\mathsf{k}}_{\mathsf{d}})$ with $d_0=1⟹x(\mathsf{p}{\mathsf{k}}_{\mathsf{d}})\ge 2^{254}$

Recall that $x(\mathsf{p}{\mathsf{k}}_{\mathsf{d}})=b_3+2^4\cdot c+2^{254}\cdot d_0$. When the top bit $d_0$ is set, we check that $x(\mathsf{p}{\mathsf{k}}_{\mathsf{d}}{)}_{\mathrm{0..}=253}<t_{\mathbb{P}}$:

1. $d_0=1⟹0\le b_3+2^4\cdot c<t_{\mathbb{P}}.$

   To check that $0\le b_3+2^4\cdot c<t_{\mathbb{P}},$ we use two constraints:

   a) $0\le b_3+2^4\cdot c<2^{140}.$ $b_3$ is already constrained individually to be a $4$-bit value. $z_{c,13}$ is the index-13 running sum output by $\mathsf{SinsemillaHash}(c).$ By constraining $$d_0\cdot z_{c,13}=0,$$ we constrain $b_3+2^4\cdot c<2^{134}<2^{140}.$

   b) $0\le b_3+2^4\cdot c+2^{140}-t_{\mathbb{P}}<2^{140}$. To check this, we decompose $b_3{c}^{\prime }=b_3+2^4\cdot c+2^{140}-t_{\mathbb{P}}$ into fourteen 10-bit words (little-endian) using a running sum $z_{b_3{c}^{\prime }}$, looking up each word in a $10$-bit lookup table. We then enforce in the custom gate that $$d_0\cdot z_{b_3{c}^{\prime },14}=0.$$