Feature: support padding with dummy epochs

[kobigurk]

Description

In order to have the circuit have a maximum number of epochs, but still support proving a smaller number of epochs, we add the support of padding with dummy epochs.

Regular epochs have index > 1.

These epochs have the following properties:

• Index = 0.
• Public keys are all the generator of G2.

We change the circuit logic to perform the following:

• Instead of enforcing the epoch index is sequential, it enforces it only if the new index is not zero.
• In the processing loop, previous_epoch_index, previous_public_keys and previous_maximum_non_signers are updated only if the index is not zero.
• The aggregated public key that's used in the miller loop for that epoch is chosen to be the generator for G2. This is conditionally chosen based on the epoch index being zero.
• The message hash that's that's used in the miller loop for that epoch is chosen to be the generator for G1. This is conditionally chosen based on the epoch index being zero.
• The over-all aggregated signature gets the generator for G1 as the contribution for that epoch. This works since sig = G1, pk = G2, H(m) = G1 satisfy e(H(m), pk) = e(sig, G2) because it's e(G1, G2) = e(G1, G2).
• The last epoch index is enforced to be non-zero.

Tested

We add tests for proofs with dummy epochs.

[kobigurk]

I didn't see this in the diff, but do you check somewhere that index[i] = 0 or (index[p] + 1), where p corresponds to the last epoch message that had a non-zero index? I think not including this would mean you can prove non-linear chains, even going back in time.

This is where the change relevant to this happened: https://github.com/celo-org/celo-bls-snark-rs/pull/179/files#diff-680350cbb026168b5a7a9366fb90840fR150.

[kobigurk]

@psivesely any more comments? :slightly_smiling_face: