Fix/plonk constraints

[ThomasPiellard]

Summary

This PR changes the way PLONK circuits are compiled. It is now faster and every cases are covered, contrary to the previous attempt at reducing the number of constraints where some cases where ignored, resulting in blowing up the number of constraints in some "big" circuits (like scalar multiplication, pairing...).

Description

The previous solution relied on factoring linear expression in Groth16 to not split them twice in PLONK. Here it is a different and simpler approach. The API has now a method that returns the backendID. If the backendID is PLONK, then the ADD and SUB methods add a new variable and the linear expression is really recorded as a constraint (it is not in GROTH16). With that, when a linear expression is reused later in the circuit, then it is the variable equal to the sum that is used, so the linear expression is split only once. Several methods in the API needed to be refactored to avoid bugs or to decrease the number of constraints, and to be consistant with the splitting algo (splitting from r1cs to sparse_r1cs).

Internal changes

Some refactoring on the constraint system has been done, to put the right fields to the right place:

• A Variable is a linear combination of Wires, and correspond to Variable as in a normal program
• A Variable has a field IsBoolean (since Boolean constraint is on the Variable level)
• A Variable no longer has a Visibility (Visibility is on the Wire level)
• A Variable no longer has an ID (the ID is on the wire level, and used only for the routing of the wires)

Internal changes:

• API has a method returning the backendID
• ADD,SUB and AssertIsBoolean are implemented differently according to the backend
• API: Select, Or, Xor have been written to ease up the conversion to sparse_r1cs
• in a constraintSystem, public, secret are now just a slice of string corresponding to the names
• in a constraintSystem, internal is now just a counter (int)
• in cs.go: variables, inputs struct have been removed
• in cs_to_r1cs_sparse: split method is simplified (no need to cover the list of sub linear expressions)
• in cs_to_r1cs_sparse: r1cToSparseR1C method just switches over a finite number of possibilities
• in cs_to_r1cs_sparse: all the logic to factorize linear expressions has been removed
• VariableID --> WireID since ID is on the Wire level (a Variable does not have an ID)
• Variable struct is now defined in compiled/variable.go
• struct Variable now contains a *bool to monitor the Variables which are boolean constrained (NOTE: we can restore the map to track Variables which are boolean constrained, for that we need to put an ID field in Variable, but it should be explicit that this field is only to track boolean constraints, and not to track the ID of wires, which are completely different)

Status

• TestCircuitStatistics fails due to a negligible delta (both + and -)
• Remaining tests pass

Ex perfs:

• compiling scalarMulG1 PLONK: 305765908 ns/op, 7928 constraints [develop] vs 10602651 ns/op, 7543 constraints[this branch]
• compiling pairing PLONK: 1762081141 ns/op, 324432 constraints [develop] vs 67556893 ns/op, 64059 constraints [this branch]

[gbotrel]

looks good, couple of comment in the review.

• Also, refactoring error "compiled.Variable" appears multiple time in comments where "variable" was fine :)
• dealing better with marking boolean constrain variables (ie Variable == LinearExpression) would remove also some of these changes (everywhere v.LinExp appears)
• minor conflicts with develop to fix before merging

[gbotrel]

here I would just merge the compiled.Variable and compiled.LinearExpression. Ie define:

type Variable []Term

Managing boolean constrained variables with a pointer seems a bit risky to me; while it may not bug with our current API, cloning a Variable, adding terms to the linear expressions, boolean constraining it will incorrectly mark the first variable as boolean constrained.

[ThomasPiellard]

We can restore the map to track boolean constrained variables, however we still need to store an ID field in Variable, right?