crate-crypto / qesa Goto Github PK

• All of the components to create the range proofs protocol are ready.

• If the amount of code for the range proof is a lot, then I will switch out the dense matrices for sparse matrices then code it.

This is a general topic.

• Each proving system / protocol layer, can be refactored irrespective of the other layers. Therefore, this task can be split up by proving systems.

We have an argument system and not a proof system

This is a general topic.

• Each proving system / protocol can be split up in a modular fashion. This issue will track the documentation of each proving system.

Currently the dense representation of matrices are being used.

• This is in-efficient.

• We can either use the traditional sparse matrix representation or we can use the representation listed in the paper.

At the moment, Qesa_Copy is not very intuitive.

• We should provide a default option which is to have a commitment_crs that is continuous as this is the average use case. If a user wants to supply a commitment_crs that is non-continuous, then it is up to them to supply the correct information.

A continuous_crs is a {1,2,3,4}

A non-continuous crs is {1,3,5,6}

• The proof creation function should compute the commitments, given that it has the set of commitment_crs' and the openings. It should return the proof along with the commitments

This is only needed when we plan to implement the shuffle example from the paper.

This is not a necessity, so it can be avoided for now.

The vandemonde_challenge func in src/math_utils.rs does not act as commented.

// Creates a vector from the scalar `x`
// contents of vector = <x, x^2, x^3,.., x^n>
// XXX: double check that it is fine to use a vandermonde matrix in regards to testing distributions to
// expand challenges instead of fetching each challenge from the distribution
// so we don't need `n` different challenges
pub fn vandemonde_challenge(mut x: Scalar, n: usize) -> Vec<Scalar> {
    let mut challenges: Vec<Scalar> = Vec::with_capacity(n);
    for _ in 0..n {
        challenges.push(x);
        x = x * x;
    }
    challenges
}

Maybe the code below is suitable?

pub fn vandemonde_challenge(mut x: Scalar, n: usize) -> Vec<Scalar> {
    let mut challenges: Vec<Scalar> = Vec::with_capacity(n);
    challenges.push(x);
    for i in 0..n-1 {
        challenges.push(challenges[i] * x);
    }
    challenges
}

There are numerous places where we use unwrap to decompress a point.

We should return a Result and propagate the error

The interactive version of the inner product argument(NoZK) allows the prover to not require the commitment.

In the interactive version, the verifier generates a random scalar challenge, without any communication with the prover. Therefore, in the non-interactive version, the prover must seed the "hash function" with the statement, in order to generate a shared view with the verifier and retrieve a challenge.

This brings up a design problem; the prover will either need to calculate P the commitment and add to transcript, P will need to be passed to the proof creation function or we assume that the caller has added P to the "hash function"/transcript.

• calculate P the commitment

This is a viable option. Note that since the prover does not use P, we would only be generating it to add it to the Merlin transcript.

• P will need to be passed to the proof creation function

This means that all callers (provers) of NoZK will need to calculate the intermediate commitments.

-assume that the caller has added P to the "hash function"/transcript

This seems like the most efficient strategy, as this is how we intend to use it. For protocols that are at the root layer, it would be fruitful to design them so that they can be used by the protocols at the higher levels, the most efficiently.

I'm not sure the meaning of Q: &RistrettoPoint of create() and verify() in lmpa module. It's never used in the function right now?