Reduce the need for extraneous generics in downstream code.

[Pratyush]

Description

Adds two main APIs:

• trait FieldWithVar: Field { type Var: FieldVar<Self, Self::BasePrimeField> }
• trait CurveWithVar<ConstraintF>: ProjectiveCurve { type Var: CurveVar<Self, ConstraintF> }

There are refactors to make this work. Primarily: we reimplement everything in terms of *_assign operators to prevent too many bounds everywhere.

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (master)
• Linked to Github issue with discussion and accepted design OR have an explanation in the PR that describes this work.
• Wrote unit tests
• Updated relevant documentation in the code
• Added a relevant changelog entry to the Pending section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer

[Pratyush]

@weikengchen is this okay? I'm using a single reduction to reduce many additions.

[weikengchen]

I think it is better to invoke the existing API add many times, which, in most cases, also does not introduce constraints.

There are two issues of the change above:

• num_of_additions_over_normal_form seems to be reset to a low number. But maybe we should sum together all the first.num_of_additions_over_normal_form and get the sum as the new element's num_of_additions_over_normal_form. Note that post_add_reduce does not always reduce---it only reduces in the extreme cases.
• post_add_reduce should better be executed after each addition, in case intermediate additions cause overflow.

[weikengchen]

in other words, post_add_reduce are cheap.

[Pratyush]

num_of_additions_over_normal_form seems to be reset to a low number. But maybe we should sum together all the first.num_of_additions_over_normal_form and get the sum as the new element's num_of_additions_over_normal_form. Note that post_add_reduce does not always reduce---it only reduces in the extreme cases.

Good point, I will sum over the additions too.

post_add_reduce should better be executed after each addition, in case intermediate additions cause overflow.

Is there a formula for that uses num_of_additions_over_normal_form to tell me whether a reduction is necessary or not?

Basically I'm trying to avoid generating large lcs.

[weikengchen]

I got your points.

Yes, the following code sets a rule. Computing this surfeit every time may be cumbersome, but it may be the more straightforward approach for this PR.

r1cs-std/src/fields/nonnative/reduce.rs

Line 138 in a2d2d47

let surfeit = overhead!(elem.num_of_additions_over_normal_form + BaseField::one()) + 1;

[Pratyush]

Ok so in the latest commit I extract that check into a common function, and now invoke it every iteration to see if a reduction is needed or not. If it is, then I invoke reduce, add this intermediate_result to a list of intermediate_results, which I manually add using the add operator.

[weikengchen]

I see. The new implementation is reasonable. Basically if limbs_iter is too heavy, we sum everything in the limbs_iter into a field element that we push to intermediate_result, which will be handled later.

[weikengchen]

Did a pass of all the code. Luckily most are refactoring.

[weikengchen]

And remember to add a CHANGELOG entry.