2 unstable releases

0.8.0 Jan 14, 2021
0.7.0 Dec 6, 2019
0.6.2 Apr 3, 2019
0.6.1 Mar 29, 2019
0.2.0 Jul 3, 2017

#2294 in Cryptography

Download history 1/week @ 2023-12-18 4/week @ 2024-01-08 8/week @ 2024-01-22 14/week @ 2024-02-19 23/week @ 2024-02-26 17/week @ 2024-03-04 22/week @ 2024-03-11 9/week @ 2024-03-18 18/week @ 2024-03-25 127/week @ 2024-04-01

180 downloads per month
Used in 4 crates (2 directly)

CC0 license

971 lines

zkp: a toolkit for Schnorr proofs

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.

Use and features

To enable the define_proof macro, import the crate like so:

extern crate zkp;

Nightly features

The nightly feature enables nightly-specific features. It is required to build the documentation.

Backend selection

zkp provides the following pass-through features to select a curve25519-dalek backend:

  • u32_backend
  • u64_backend
  • simd_backend

Transcript debugging

The debug-transcript feature is for development and testing, and prints a log of the data fed into the proof transcript.

Autogenerated benchmarks

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:

  • Add a bench feature to your crate's Cargo.toml;
  • Add #[cfg_attr(feature = "bench", feature(test))] to your crate's lib.rs or main.rs, to enable Rust's nightly-only benchmark feature.



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.


~78K SLoC