mirror of
https://github.com/Sunscreen-tech/Sunscreen.git
synced 2026-01-14 16:17:56 -05:00
badb8f9c8f
* Export type alias for bulletproof backend fields Also, keep bulletproof stuff namespaced to a `bulletproofs` module. * Change sudoku to use pub over const * Docs updates * Rename / clean up sudoku * Export `Proof` type Basically required for being able to deserialize a proof * Add zkp/serde workspace example * Drive by cleaning * Exports necessary for gadget impls * Rename compute_inputs to compute_hidden_inputs * Add prove/verify builders * Export the builder types This isnt strictly necessary but it would be weird for these to not show up in the cargo docs * Clippy fix * Add helper .compile() & .runtime() methods to fhe prog fns I do wonder if these should be defined in a separate trait, just so that they don't live next to the more internal functions in documentation. * Use new swag to simplify the front-facing api docs example * Add some whitespace * Switch to an extension trait * Add an extension to ZkpProgramFn * Take an owned ZkpBackend, rather than reference Its typical to have the caller handle cloning, rather than taking a reference, requiring Clone impl, and forcing clone. Plus, as of now the only backend is a zero size null struct, so nothing to be gained by using a reference. It also just looks weird to always pass `&BulletproofsBackend::new()` * Update sudoku to use new swag * Target second attribute in multi attribute error * Enforce ordering zkp inputs: constants,public,private Honestly this feels a little unnatural to me. Might want to reverse: private, public, constant and then change all the prove/verify methods to that ordering * Build whitelist example in CI * Reorder constant->public->private to private->public->constant * Fix trailing ws * Fix example * Make .runtime() more consistent with .compile() * Get rid of some boilerplate impls * Add custom zkp type example * Move example run checks into example tests Should speed up CI a bit * Change whitelist -> allowlist
763 B
763 B
allowlist
This example shows a possible project layout using cargo workspaces. The
prover and verifier are separate crates and refer to the common zkp crate
for the ZKP program definition.
When the prover and verifier live on different machines, they'll probably
communicate by sending the serialized proof over a network call. However, we can
demonstrate a similar scenario by having them communicate as separate processes,
piping a serialized proof from prover stdout to verifier stdin.
In this allowlist zkp, the verifier verifies that the prover has an entry on its public allowlist, without revealing which entry. The allowlist is hardcoded to the numbers 100 to 199 inclusive.
cargo run -p prover -- 101 | cargo run -p verifier