Therefore it's important to be sure when we can or cannot use one of these variables for ECC ops purposes.
There is one thing which is actually not doable (directly using PLONK) which is the fact of transforming a BlsScalar into a JubJubScalar after hashing in order to use the result of the hash as the JubJubScalar used to perform the scalar mul.
To do so, we will need to refactor the Variable struct to differenciate between Bls and JubJub and also, implement a gate (without a commitment requirement) that will perform this operation returning a different variant of the enum.
The possible conversions are:
Variable::JubJub -> Variable::Bls: (No cost or gates involved (FREE))
Variable::Bls -> Variable::JubJub: We need to perform what has been now included inside of this PR also replacing the hardcoded constant by a constant in this crate.
marta-belles
commented
10 months ago
We have places in our code where the
Variabletype holds a value that can be mapped securely to aJubJubScalar. See for example: https://github.com/dusk-network/plonk/blob/master/src/constraint_system/ecc/scalar_mul/variable_base/mod.rs#L11-L34Therefore it's important to be sure when we can or cannot use one of these variables for ECC ops purposes.
There is one thing which is actually not doable (directly using PLONK) which is the fact of transforming a
BlsScalarinto aJubJubScalarafter hashing in order to use the result of the hash as theJubJubScalarused to perform the scalar mul.To do so, we will need to refactor the
Variablestruct to differenciate betweenBls and JubJuband also, implement a gate (without a commitment requirement) that will perform this operation returning a different variant of the enum.The possible conversions are:
Variable::JubJub->Variable::Bls: (No cost or gates involved (FREE))Variable::Bls->Variable::JubJub: We need to perform what has been now included inside of this PR also replacing the hardcoded constant by a constant in this crate.