Fix ecrecover input rlc comparison (right-padding zeroes)

[roynalnaruto]

Description

Input RLC comparison in precompiles ecrecover, ecAdd, ecMul` can fail as inputs are right-padded with zeroes. Since those zeroes were not accounted for in the copy circuit, the RLC value was incorrect.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Rationale

We add a lookup table PowOfRand which represents the below table:

exponent	power of randomness
0	1
1	r
2	r ^ 2
...	...
126	r ^ 126
127	r ^ 127

where r represents the keccak randomness (which is used as the randomness to calculate RLC of input bytes in the copy circuit).

The precompiles ecrecover, ecAdd and ecMul expect 128, 128 and 96 input bytes respectively, but if the calldata does not have sufficient number of bytes, zero bytes are padded to the right before running the precompile computation.

We use the following approach:

// no. of right padded zeroes is the difference between required input length and calldata length.
let n_padded_zeroes = input_len - calldata_len;
cb.range_lookup(n_padded_zeroes.expr(), 128);

// cell to hold the RLC value with padded zeroes.
let padded_input_rlc = cb.query_cell_phase2();

// get the power of randomness we are interested in.
let power_of_rand = cb.query_cell_phase2();
cb.lookup_pow_of_rand(n_padded_zeroes.expr(), power_of_rand.expr());

// validate value of padded RLC.
cb.require_equal("rlc eq", padded_input_rlc.expr(), input_rlc.expr() * power_of_rand.expr());

[lispc]

a bit concern. when cb.condition(pad_right.expr() is false, i think the constraints inside PaddingGadget is all disabled. so there are no constraints to enforce relationship between padding_gadget.padded_rlc and input_bytes_rlc/cd_length/input_len when pad_right == false.

[roynalnaruto]

That's a very good catch. I will handle input_bytes_rlc == padded_rlc if pad_right == false

[lispc]

i think cb.pow_of_rand_lookup(0, 0) is valid (of course it is not part of the first 128 rows we assigned but following rows, default value there is all 0, so pow_of_rand_lookup(0, 0) is valid).

Will this behavior be ok for soundness? if ok, then we can add some comments above the pow_of_rand_table definition, if not ok, we can add the "fixed" q_enable col.

ref:
privacy-scaling-explorations#866
#471