Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ConstraintSystem::constrain(): check validity of LinearCombinations. #278

Open
rubdos opened this issue Jun 6, 2019 · 0 comments
Open

Comments

@rubdos
Copy link
Contributor

rubdos commented Jun 6, 2019

I found these lines in prover.rs:

fn constrain(&mut self, lc: LinearCombination) {
// TODO: check that the linear combinations are valid
// (e.g. that variables are valid, that the linear combination evals to 0 for prover, etc).
//[..]
}

I tried implementing this, since I have some issues debugging a proof system I built. I've written:

    fn constrain(&mut self, lc: LinearCombination) {
        let sum: Scalar = lc.terms.iter().map(|(v, s)| {
            let l = match v {
                Variable::One() => Scalar::one(),
                Variable::Committed(i) => self.v[*i],
                Variable::MultiplierLeft(i) => self.a_L[*i],
                Variable::MultiplierRight(i) => self.a_R[*i],
                Variable::MultiplierOutput(i) => self.a_O[*i],
            };
            l * s
        }).sum();
        debug_assert_eq!(sum, Scalar::zero());
        // TODO: check that the linear combinations are valid
        // (e.g. that variables are valid, that the linear combination evals to 0 for prover, etc).
        self.constraints.push(lc);
    }
}

Which works but it changes the behaviour of the method. Certain tests (e.g. example_gadget_test()) started failing, because now the prove system does not return Err on validation, but panics earlier.


Another option would be to return Result<(), R1CSError> in fn constrain, but that alters the signature for ConstraintSystem (and thus for verifier, who will always return Ok(()) anyhow). It would also not allow to disable this behaviour on --release builds.


What kind of implementation for this TODO would you consider best? Maybe even something different from my proposals?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant