Modify the packing policy to reduce the number of primary inputs processed by the Verifier

[AntoineRondelet]

In the current state of the project, several primary inputs are digest (of bit-length 256) and are packed into field elements. This set of field elements represent the set of primary inputs sent to the Verifier (contract), which then executes the SNARK verification routine. The verification routine of the SNARK used does a number of scalar multiplications linear in the number of primary inputs.

For now, each 256-bit digest (d) is packed into 2 field elements:

1. d1: One field element containing 253 bits from the digest
2. d2: Another field element containing the 3 remaining bits of the digest (and all zeroes afterwards)
   This "packing policy" was chosen to keep things simple, but we clearly see that, if we have the following set of primary inputs:
   {rt, n1, n2, c1, c2, vpub_in, vpub_out}, where {n1,n2,c1,c2} are digests, then, we'll send the set {rt, n11, n12, n21, n22, c11, c12, c21, c22, vpub_in, vpub_out} of field elements as the set of primary inputs, to the Verifier.

This is quite inefficient since we know that {n12, n22, c12, c22} will only contain 3 "meaningful bits" (the other bits in the field element representation will be set to 0's).

It'd be better to represent the information of the set {n12, n22, c12, c22} in a single field element.

Doing so would reduce the cardinality of the set of primary inputs and save a few calls to the bn256ScalarMul precompiled contract, saving gas on the Verifier side.

[AntoineRondelet]

This requires changes in the circuit (to change the way we pack the primary inputs) and changes on the solidity side (to parse and recompose the digests from the packed elements - some "utils" functions will need to be modified/implemented).

It will save constraints in the circuit and save gas cost on the verifier's side.

[rrtoledo]

Issue #55 can be incorporated here.

[rrtoledo]

Could we go a step further in the packing ?
v_in and v_out each needs only 64 bits. A field variable being written over 253 bits, we could pack v_in, v_out and the {n12, n22, c12, c22, hsig2, h02, h12} into a single field variable (2*64+3*(2* NumInput + 1 + NumOutput) = 146 bits < 253 ).

[AntoineRondelet]

Yes, I think this is fine to include the v_in and v_out values in the resulting field element @rrtoledo
You'll need to make sure you can extract these values on the contract (like for other public inputs) to carry out all the relevant checks.

[AntoineRondelet]

Closing this issue since the corresponding PR has been merged