Open mimoo opened 6 months ago
I think we would still need to add_constant
to constraint constants.
For this case in the mul constraint:
let zero = compiler.backend.add_constant(
Some("encoding zero for the result of 0 * var"),
B::Field::zero(),
span,
);
It is an "empty" constraint, as it constraint a zero constant and the purpose is to avoid creating a gate. So this constraint is ineffective and unnecessary.
But for the case in equal_cells
:
let x1 = match x1 {
ConstOrCell::Const(cst) => compiler.backend.add_constant(
Some("encode the lhs constant of the equality check in the circuit"),
*cst,
span,
),
ConstOrCell::Cell(cvar) => *cvar,
};
let x2 = match x2 {
ConstOrCell::Const(cst) => compiler.backend.add_constant(
Some("encode the rhs constant of the equality check in the circuit"),
*cst,
span,
),
ConstOrCell::Cell(cvar) => *cvar,
};
It needs to enforce the equality with the constants, so the constraints for these constants need to be presented in the circuit.
This add_constant
does two things:
So if we want to remove this interface, we would need to replace it with
new_internval_var
constraint_eq_const
(this is a newly added backend interface without returns)
We should audit the usage of
add_constant
function. I have a feeling that it should be abstracted away, and the backend should decide if constants need to be created by adding a constraint. That’s in the case of plonk, r1cs doesn’t seem to care about that.For example, one use of
add_constant
is in themul
function:we need this at the moment because we return a
Var
which cannot represent a constant here. But would it make sense to return aConstOrCell
instead so that we can return a constant here?Exploring if this is possible should be fairly easy hence the tag