This crate has a toolkit for Schnorr-style zero-knowledge proofs, instantiated using the ristretto255 group.
It provides two levels of API:
a higher-level, declarative API based around the define_proof macro,
which provides an embedded DSL for specifying proof statements in
Camenisch-Stadler-like notation:
define_proof! {
vrf_proof, // Name of the module for generated implementation
"VRF", // Label for the proof statement
(x), // Secret variables
(A, G, H), // Public variables unique to each proof
(B) : // Public variables common between proofs
A = (x * B), // Statements to prove
G = (x * H)
}
This expands into a module containing an implementation of proving,
verification, and batch verification. Proving uses constant-time
implementations, and the proofs have a derived implementation of
(memory-safe) serialization and deserialization via Serde.
a lower-level, imperative API inspired by Bellman, which
provides a constraint system for Schnorr-style statements. This
allows programmable construction of proof statements at runtime. The
higher-level define_proof macro expands into an invocation of the
lower-level API.
The lower-level API is contained in the toolbox module.
Examples of how to use the API can be found in the library's tests
directory.
Currently, the examples include:
Specification of an "anonymous credential presentation with 10 hidden attributes" proof from CMZ'13. Depending on the backend selection, the generated implementation is between 20 to 40 times faster than the benchmark numbers reported in that paper.
A transcript-based signature and VRF construction with an auto-generated implementation. This includes an example of using the online interactive composition described in the Merlin blog post to provide chained signatures with a counterparty.
An example of using the lower-level constraint system API.
To enable the define_proof macro, import the crate like so:
```
extern crate zkp; ```
The nightly feature enables nightly-specific features. It is required
to build the documentation.
zkp provides the following pass-through features to select a
curve25519-dalek backend:
u32_backendu64_backendsimd_backendThe debug-transcript feature is for development and testing, and
prints a log of the data fed into the proof transcript.
The define_proof macro builds benchmarks for the generated proof
statements, but because these are generated in the client crate (where
the macro expansion happens), they need an extra step to be enabled.
To enable generated benchmarks in your crate, do the following:
bench feature to your crate's Cargo.toml;#[cfg_attr(feature = "bench", feature(test))] to your crate's
lib.rs or main.rs, to enable Rust's nightly-only benchmark
feature.THIS IMPLEMENTATION IS NOT YET READY FOR PRODUCTION USE
While I expect the 1.0 version to be largely unchanged from the current code, for now there are no stability guarantees on the proofs, so they should not yet be deployed.