dalek-cryptography / zkp Goto Github PK

Restructure the existing tests so that each test file contains a proof statement and some example code showing how that statement is used.

For instance, CompactProof does not implement Debug.

I'm getting the following errors when trying to compile code sig_and_vrf_example.rs.
Rust version: 1.47.0

ERROR 1
error[E0308]: mismatched types
--> src/main.rs:91:20
|
91 | x: &self.sk.0,
| ^^^^^^^^^^ expected struct zkp::curve25519_dalek_ng::scalar::Scalar, found struct curve25519_dalek::scalar::Scalar
|
= note: expected reference &zkp::curve25519_dalek_ng::scalar::Scalar
found reference &curve25519_dalek::scalar::Scalar

Cargo.tml
...
[dependencies]
zkp = "0.8.0"
rand = "0.7"
curve25519-dalek = { version = "2", default-features = false, features = ["serde", "std"] }

[features]
default = ["u64_backend"]
u32_backend = ["curve25519-dalek/u32_backend"]
u64_backend = ["curve25519-dalek/u64_backend"]
simd_backend = ["curve25519-dalek/simd_backend"]

ERROR 2
Also, if trying using the latest version of rand and curve25519, get a different error:
error[E0277]: the trait bound R: zkp::rand::RngCore is not satisfied
--> src/main.rs:49:34
|
49 | SecretKey(Scalar::random(rng))
| ^^^ the trait zkp::rand::RngCore is not implemented for R
|
::: /home/oracle/.cargo/registry/src/github.com-1ecc6299db9ec823/curve25519-dalek-3.0.2/src/scalar.rs:558:22
|
558 | pub fn random<R: RngCore + CryptoRng>(rng: &mut R) -> Self {
| ------- required by this bound in curve25519_dalek::scalar::Scalar::random
|
help: consider further restricting this bound
|
48 | fn new<R: RngCore + CryptoRng + zkp::rand::RngCore>(rng: &mut R) -> SecretKey {
| ^^^^^^^^^^^^^^^^^^^^

Cargo.toml
...
[dependencies]
zkp = "0.8.0"
rand = "0.8.3"
curve25519-dalek = "3.0.2"

The current implementation uses the create_nipk macro to generate standalone modules for each proof statement. But all of the proof statements have to be known at compile time, and it's not possible to define proof statements programmatically.

To fix this, the crate should be rewritten in the following way: there should be a new constraint system API for defining Schnorr constraints (i.e., exactly the language which is currently supported, an AND of a bunch of linear combinations of public variables by witness variables). Then, the existing create_nipk macro should be rewritten to use that API internally, instead of just generating code directly.

What should the constraint system API look like? Drawing on the Bellman and Bulletproofs APIs, it should have the following pieces:

• a SchnorrCS trait with methods for:
  • allocating and assigning instance variables (the variable assignments are RistrettoPoints)
  • allocating and assigning witness variables (the variable assignments are Option<Scalar>s)
  • adding a constraint (an LHS instance variable constrained to equal a linear combination of instance variables by witness variables)
• a ProverCS type implementing the SchnorrCS trait. The ProverCS should have a prove(mut self) method that consumes the constraint system to produce a proof, or maybe multiple proving methods for different kinds of proofs (e.g., compact vs batchable).
• a VerifierCS type implementing the SchnorrCS trait. The VerifierCS should have a verify(mut self, ...) method that consumes the constraint system to verify a proof (again, maybe multiple, in case there are multiple proof formats).

This API can coexist with the current macro, because the two would sit at different levels: the constraint system API has the user declare their proof statements programmatically, while the macro has the user declare them declaratively.

This might look like "use cargo expand" before deploying the code

Currently the ProveAssignments and VerifyAssignments force redundant compressions / decompressions because they require that all assignments are either compressed or uncompressed. Instead, they should use an enum to allow either or both (i.e., if the caller has both the compressed and uncompressed forms, there should be no additional work).

The existing documentation should be moved into a markdown file that explains the two levels of the API (declarative / imperative), and has a description of the design choices.