Weikeng Chen

One `RcCell` per emulated field variable is a possible solution, though it seems to introduce too many RcCell, and may have performance overhead. The best way, which would be more...

or `$size + log2(operands.len() + 1)`?

The need to support zero bases for a non-zero exp when using NAF has something to do with Poseidon. It is very possible for Poseidon to be powering "0" to...

The zero-base zero-pow issue is also discussed in https://github.com/arkworks-rs/algebra/pull/303. If we decide that 0^0 = 1, then this PR can also be simplified somehow (note, only the beginning part).

It would be great if there is a global macro that helps write hash-to-the-curve, so individual programs just call something like: ``` hash_to_curve!(G1, format!("Transparent setup {}", i)); ```

Based on what I know, the `ParametersVar` has always been a trivial copy of `Parameters` in our current implementations, so it does not add any new constraints? It would still...

In PedersenCRH it seems that this change would be trivial since the current ParametersVar simply invokes Parameters. ``` #[derive(Derivative)] #[derivative(Clone(bound = "C: ProjectiveCurve, GG: CurveVar"))] pub struct CRHParametersVar where for

We probably would leave this issue for the future. It requires too many changes upstream, while the necessity is small.

:) just realized that merge requires all the tests to pass -> let us wait for a few PRs to be stable before moving forward, otherwise our patches.io will need...

This PR now contains all changes needed for the PR to pass, though it relies on a few branches of pending PRs in other repos.