feat: use precomputation on (most) fixed generators

[AaronFeickert]

Uses precomputation of fixed generator vectors to speed up verification, at the cost of storing precomputation tables between verification operations. This doesn't use precomputation on the Pedersen generators, since those can be set independently of the others, and we can't mix-and-match precomputation tables due to upstream limitations.

Note that this requires and uses a custom curve library fork. The fork supports partial precomputation by removing an existing restriction about matching the number of static points and scalars used for precomputation evaluation. It also implements Clone on the underlying types used for precomputation. This is unfortunate, since due to their size (several megabytes in total) such tables should almost certainly never be cloned. However, it's done for the reason explained below.

The generator tables are wrapped in an Arc for shared ownership. This is done because precomputation evaluation is an instance method on a precomputation type, not a static method that takes a reference to the underlying tables. I have no idea why this design was chosen (static methods are used for other types of multiscalar multiplication), especially because there's no mutation involved. But because of this, the verifier needs to own the precomputation structure containing the tables, even though those tables are expected to be reused (that's the entire point of precomputation). Using an Arc takes care of this nicely, and avoids cloning.

However, apparently #[derive(Clone)] only plays nicely with structs if all included generic types implement Clone, which means even though cloning the table Arc isn't any kind of deep copy, we can't use that attribute unless the precomputation tables implement Clone. Manually implementing Clone on the containing struct is a headache, so it seemed easier just to add #[derive(Clone)] at the curve library level.

This means it's probably very important to ensure that precomputation tables are used very carefully to avoid unintended cloning. I did some testing and confirmed that the current implementation handles this as expected, and won't clone any of the tables, despite the compiler requiring they implement Clone.

Closes issue #18.

[stringhandler]

I think you will struggle to get that PR into dalek, but worth a try. Looks ok at first glance otherwise

[AaronFeickert]

I think you will struggle to get that PR into dalek, but worth a try. Looks ok at first glance otherwise

Agreed that it seems very unlikely for an upstream PR to be accepted, and I didn't plan on doing one. I think it would need to remain a fork. However, keeping a maintained fork would also allow for more flexibility on future changes to the curve library.

[AaronFeickert]

This will be ready to review once a curve library PR is merged and tagged, at which point this PR can use it as a dependency.

[stringhandler]

@AaronFeickert I've merged the curve library PR and created a tag

[SWvheerden]

This looks good.
I am mostly happy with it except for the copy. Expensive types should not have copy as an implementation.

The reason is two-fold:

• Types that impl copy are not moved when used in a function, they are copied
• If a type impl copy it hides expensive copying by always doing mem copy and not doing a move which is more desirable and or pointing out to the dev that a clone is happening here,

[SWvheerden]

This is more going in the right direction

[AaronFeickert]

This is now an upstream PR.