Flexible Input/Output circuits

[IlyasRidhuan]

This PR closes #818 and closes #262 and removes the need for specific circuits based on the commitments and nullifiers. Instead we have 3 circuits (deposit, transfer, withdraw) that can support variable number of commitment/nullifiers. There are considerable changes to the way the circuits and commitment selection works in this PR.

Circuits

1. The circuits are refactored to make liberal use of generics across the key verify functions (e.g. verify_nullifier, verify_commitment and verify_structure).
2. The public transaction struct has been included as part of the public input to the proof. This means the circuit also performs the structural check for the validity of the transaction struct itself. This heavily simplifies the challenges as we no longer need to have a specific transaction structure challenge.

Operation	Constraints Before	Constraints After	% Change
Deposit	619	921	+48%
Single Transfer	26,320	39,363	+50%
Double Transfer	39,295	39,363	+0.01%
Withdraw	12,075	26,050	+112%

Note: There is no longer a specific single_transfer circuit as the transfer circuit handles all scenarios (hence the constraint is as large as possible to also handle double_transfer). Similarly, withdraw must be able to accommodate the most complex scenario of 2 inputs with a single output, which increases the constraints significantly.

Commitment Selection

We now have the flexibility to better select the type of transaction that will be performed based on the current user's UTXO (notes). Previously, commitment selection was based on:

1. Perform a single transfer when possible
2. Else perform a double transfer if the total inputs were greater than the required output
   Note: A double transfer would fail if the sum of inputs were equal to the required output (i.e. it had to be strictly greater than). Withdraw's needed to be of exact value.

With the new flexible circuits we perform the following checks

1. Perform a single transfer if possible.
2. Perform a double transfer without change if we have a sum of inputs that match the exact value.
3. Perform a single transfer with change if we have a single input > output required
4. Perform a double transfer with change otherwise.

This is still subject to change, especially in the prioritising of (3) and (4). Note that a withdraw now attempts to do (1) to (3) instead of being restricted to an exactly matching input.

Testing

This can be tested by running npm run test-circuits while nightfall is running

[RogerTaule]

Why the firstInputZkpPublicKeys inicialization was removed?

[RogerTaule]

If we set Commitments<1> in the withdraw.zok, withdraw_stub.zok needs to also be updated

Outdated

[RogerTaule]

Looks good to me :)