Leios design: Cryptography - Voting, Certificate

[curiecrypt]

A draft of the technical design for cryptographic primitives for the voting mechanism and certificate scheme.

This PR contributes to #542.

[curiecrypt]

Please see my comment, @hjeljeli32.

• Regarding the following

Consider the modifications to also cover Peras-related/specific features.

I suggest we first address the first two items as @ch1bo suggested. Then we can ask the Peras people to review this PR and decide what, if any, additional modifications are needed based on their feedback.

After that, I think we can merge this into main and leave the Potential Risks and Mitigations part to be completed in a follow-up PR. WDYT @ch1bo, @hjeljeli32?

[bwbush]

Including the 48 bytes for the signed aggregated of the election proofs has a significant performance advantage:

• Verifying the aggregate proof means that one does not have to verify the numerous eligibility signatures.
• One can just use the VRF which is the eligibility signature to determine how many seats the pools has on the committee. This doesn't involve any BLS group operations.

[ch1bo]

@perturbing Does this comment change the design decisions? I don't really understand the suggestion, but it sounds interesting?

[perturbing]

Hmmm, also not entirely sure what @bwbush is alluding to in this context.

This section is about certificates 🤔

Certificates will not contain eligibility proofs (votes do).

Also note, we can aggregate eligibility proofs into one for many non-persistent voters, as each signs over the same message (something like hash(slot of EB | Praos epoch nonce)), but this has no practical value, as this new aggregate signature is no longer a VRF output of each party (so you cannot derive any eligibility check from it).

Bottom line: Aggregation is done in the context of signature schemes, not VRFs. So even though technically, the VRF output here is also a signature, its aggregated form loses the VRF context.

[perturbing]

Just for the record, I understand the remark made now.

As mentioned by @hjeljeli32

Leios does not aggregate eligibility proofs.

Which is true, so each bls signature must remain in the certificate. That said, to use the signature as a vrf, you have to check its validity. @bwbush remark is that, we can optionally add another aggregated signature over the eligibility proofs, so that we can do this validity check in one batch.

Currently, the formal spec has an optional field for this, but tbh, I think we need to make it mandatory (though this would add some cost on the critical path of EB cert creation, (as the producer needs to aggregate the eligibility proofs). That said, on mainnet we have sub-100 non-persistent voters, probably manageable.

[ch1bo]

@perturbing what shall we do with these changes, can you take ownership of these parts on the technical design document?

[perturbing]

@ch1bo , will do. Given our recent discussion, I think we can make some statements more exact and precise