Expose and use precomputation tables for commitment generators

[AaronFeickert]

Precomputation tables for fixed generators, like those used in commitments and public keys, can provide significant relative performance benefits in scalar-group multiplication operations. The "default" group generator G already has a table hardcoded in the curve library, and the API allows you to generate tables for any group element you wish. Aside from using tables for function-based operations like commitments, it may additionally be useful to expose references to these tables for higher-level protocol operations (like commitment signatures) that handle their own scalar-group multiplications.

An unfortunate downside of the dalek API is that it handles scalar-group multiplication precomputation differently than for multiscalar multiplication operations, and the latter is quite inflexible. There are a few options for how to handle these limitations, some of which might necessitate a custom fork of the curve library to expose some of the guts of the implementation.

For reference, local benchmarks suggest a 60% performance gain for generating a Pedersen commitment with the use of precomputation tables for both generators, relative to the use of constant-time multiscalar multiplication with no tables.

[AaronFeickert]

One option for this could be to generate precomputation tables dynamically when a PedersenCommitmentFactory is created. However, this breaks the "it's cheap to create factories" guideline implied in the code comments.

Another option is to generate precomputation tables statically along with NUMS points. Most of them won't be used, however.

A middle ground could be statically creating only the standard H point's table with the NUMS points. Then creation of a PedersenCommitmentFactory could store references to it and the standard G point's table in the default case, or generate new tables in the non-default case. This would make the default case efficient even if the factory is created multiple times.

[hansieodendaal]

AaronFeickert@5d0aa49

[AaronFeickert]

AaronFeickert@5d0aa49

This is just a first attempt, and is probably not the best way to approach the issue. Comments and suggestions welcome!