ZK Tools / Toolkit

A full stack of small, composable parts.

Start with circuit semantics, choose a proof system, then add the hash, tree, signature, or browser boundary your application needs.

Crate map

Know where each responsibility lives.

01dusk-zk-composerShared circuit-construction language with PLONKish and R1CS backends.foundation

02dusk-groth16Circuit-specific Groth16 setup, proving, verification, keys, and proofs.proof system

03dusk-plonkPLONK with KZG commitments, custom gates, transcripts, and debugging.proof system

04dusk-poseidonNative and in-circuit Poseidon hashing with domain-separated sponge construction.primitive

05dusk-merkleSparse, height- and arity-parameterized trees with custom aggregation.data structure

06poseidon-merklePoseidon aggregation and optional in-circuit Merkle opening verification.gadget

07jubjub-schnorrSingle, double-key, variable-generator, multisignature, and circuit verification.signature

08plonkwasmProof, verification, serialization, and JSON-oriented helpers for WebAssembly frontends.wasm bridge

Proof systems

Same statement, different operational profile.

The shared circuit API keeps application logic stable while setup, constraint lowering, proof encoding, and compatibility remain explicit.

GROTH16 / R1CS

Compact, circuit-specific

Uses a circuit-specific single-party setup. Proofs have a fixed 192-byte canonical compressed encoding. The circuit's canonical R1CS shape is bound into the proving key, and its verification key can generate an EIP-2537 Solidity verifier.

View source ↗

PLONK / PLONKISH

Reusable parameters, custom gates

Compiles against reusable KZG public parameters and supports optimized custom gates, a circuit debugger, and current plus legacy proof verification.

View source ↗

Primitives and gadgets

The cryptographic pieces applications repeatedly need.

Poseidon

Field-native hashing, Hades permutation, SAFE sponge construction, and domain separation.

Merkle trees

Sparse trees with configurable height, arity, aggregation, and zero-knowledge openings.

Schnorr

JubJub signatures with native and in-circuit verification, including double-key variants.

WebAssembly

Move proofs and ordered scalar inputs through a compact JSON-oriented browser ABI.

Select one curve backend

Consumers must explicitly choose exactly one BLS12-381 backend: bls-backend-blst or bls-backend-dusk. Keep that choice aligned across crates which exchange curve values.

Cargo.toml

[dependencies]
dusk-poseidon = {
  version = "0.42",
  default-features = false,
  features = ["bls-backend-blst"]
}

Plan for allocation separately from std

Several crates split alloc from std. The root Makefile checks supported bare-metal and WebAssembly configurations with the portable backend.

Treat archives as backend-sensitive

When rkyv-impl stores backend-specific curve representations, do not deserialize an archive after changing backends without an explicit migration. Proof formats, public-input ordering, transcript labels, and circuit shapes should receive the same compatibility discipline.

API and source reference

← Core concepts Try the examples →