Crate zkboo 

A no_std implementation of the ZKBoo protocol, using ZKB++ optimisations.

🚧 Warning: This crate is work in progress, not yet suitable for use in production. 🚧

Generic Parameters

The protocol logic is generic over implementations of the following primitives:

• An implementation C: Circuit of the desired circuit logic. Used by execution, proof generation and proof verification.
• An implementation H: Hasher of the cryptographic hash function used to compute view commitments and to generate the stream of pseudo-random challenges. Used by proof generation and proof verification.
• An implementation PS: PseudoRandomGenerator of the pseudo-random generator used to generate view seeds. Used by proof generation only.
• An implementation PV: PseudoRandomGenerator of the pseudo-random generator used to generate entropy for AND messages in the view execution and reconstruction logic. Used by proof generation and proof verification.
• An implementation S: Seed of the type used for view seeds.

The pseudo-random generators can be built from the same cryptographic hasher H: Hasher used for view commitment and challenge generation, using the HashPRG<H> wrapper for PS/PV and the digest type <H as Hasher>::Digest for S.

Circuit Implementation

ZKBoo circuits are defined by implementing the Circuit trait. The Circuit::exec method must encapsulate the full circuit execution lifecycle, featuring:

• Input allocation via Frontend::input.
• Constant allocation via Frontend::alloc.
• Execution via WordRef methods/operations.
• Output production via Frontend::output.

A circuit implementation will typically feature two constructors:

• A new constructor for execution and proof generation, taking secret input information.
• A dummy constructor for proof verification, using dummy values for input information.

The proof verification logic does not use the value of input words, but their type/width remains relevant for the purpose of internal memory management.

The WordRef struct provides an abstraction for words in the circuit state, allowing the circuit to define its logic independently on the underlying choice of Backend. This allows the same circuit implementation to be used for plain execution, proof generation, proof verification, and much more.

WordRefs mirror Rust’s ownership model, requiring explicit clone for multiple use and allowing automatic memory management for circuits via RAII. A Frontend wrapper is used to manage the Backend lifecycle, enforce its invariants, and provide convenient access to for word allocation methods and finalization.

Proof Generation

The prover module implements proof generation logic:

• The prove function can be used to build a ZKBoo proof in memory.
• The prove_custom function allows for complete customisation of the proof building process via a user-provided implementation of a ResponseDataCollector.
• The par_prove function variant of prove using rayon to generate responses in parallel.

Proof Verification

The verifier module implements proof verification logic:

• The verify function can be used to verify a ZKBoo proof in memory.
• The par_verify function variant of verify using rayon to verify responses in parallel.

Word Containers

The implementation provides support for native Word types corresponding to Rust’s primitive unsigned integer types: u8, u16, u32, u64 and u128. All logic is monomorphised over word type, with no dynamic dispatch or boxing, and support for all desired word types must be enabled via Cargo features.

The Words structure defines a container for vectors of words, with vector indexing explicitly tagged by word type for the purpose of monomorphisation. The Shape struct is used to specify the number of words for each type, and ShapeError is used to report shape mismatches.

It is important to understand that indexing of words within these containers is not absolute, but rather relative to the position of words of the same type. This is different from common conventions in circuit frameworks, where indexing is absolute and a sequence of word types is specified as part of signatures.

Features

• u16 enables support for 16-bit words
• u32 enables support for 32-bit words (enabled by default)
• u64 enables support for 64-bit words (enabled by default)
• u128 enables support for 128-bit words
• parallel enables parallel proving/verifying using the rayon crate

Support for u8 words is enabled by default.

Modules

backend

Implementation of generic backend functionality.

circuit

Trait and macros for ZKBoo circuits.

crypto

Traits and implementations for cryptographic hashers and pseudo-random generators.

executor

Implementation of the execution logic for ZKBoo circuits.

memory

Implementation of memory management for generic ZKBoo backends.

prover

Implementation of the ZKBoo proof generation logic.

utils

Assorted utilities for the crate.

verifier

Implementation of the ZKBoo proof verification logic.

word

Implementation of word containers.