55//! The idea is to represent each relation to be proved as a [`Statement`], and any relations between
66//! [`Statement`]s as a [`MetaStatement`]. Both of these types contain public (known to both prover
77//! and verifier) information and are contained in a [`ProofSpec`] whose goal is to unambiguously
8- //! define what needs to be proven. The prover then uses a [`Witness`] per [`Statement`] and creates a
9- //! [`StatementProof`] per [`Statement`]. All [`StatementProof`]s are grouped together in a [`Proof`]
10- //! and the verifier then uses the [`ProofSpec`] and [`Proof`] to verify the proof. Currently it is
8+ //! define what needs to be proven. Some [`Statement`]s are specific to either the prover or the verifier
9+ //! as those protocols require prover and verifier to use different public parameters. An example is Groth16
10+ //! based SNARK protocols where the prover needs to have a proving key and the verifier needs to
11+ //! have a verifying key. Both the prover and verifier can know both the proving and verifying key but
12+ //! they don't need to thus for such protocols, there are different [`Statement`]s for prover and verifier,
13+ //! like [`SaverProver`] and [`SaverVerifier`] are statements for prover and verifier respectively,
14+ //! executing SAVER protocol.
15+ //! Several [`Statement`]s might need same public parameters like proving knowledge of several BBS+
16+ //! from the same signer, or verifiable encryption of several messages for the same decryptor. Its not
17+ //! very efficient to pass the same parameters to each [`Statement`] especially when using this code's WASM
18+ //! bindings as the same values will be serialized and deserialized every time. To avoid this, caller can
19+ //! put all such public parameters as [`SetupParams`] in an array and then reference those by their index
20+ //! while creating an [`Statement`]. This array of [`SetupParams`] is then included in the [`ProofSpec`]
21+ //! and used by the prover and verifier during proof creation and verification respectively.
22+ //!
23+ //! After creating the [`ProofSpec`], the prover uses a [`Witness`] per [`Statement`] and creates a
24+ //! corresponding [`StatementProof`]. All [`StatementProof`]s are grouped together in a [`Proof`].
25+ //! The verifier also creates its [`ProofSpec`] and uses it to verify the given proof. Currently it is
1126//! assumed that there is one [`StatementProof`] per [`Statement`] and one [`Witness`] per [`Statement`]
1227//! and [`StatementProof`]s appear in the same order in [`Proof`] as [`Statement`]s do in [`ProofSpec`].
28+ //!
1329//! [`Statement`], [`Witness`] and [`StatementProof`] are enums whose variants will be entities from different
14- //! protocols. Each of these protocols are variants of the enum [`SubProtocol`].
30+ //! protocols. Each of these protocols are variants of the enum [`SubProtocol`]. [`SubProtocol`]s can internally
31+ //! call other [`SubProtocol`]s, eg [`SaverProtocol`] invokes several [`SchnorrProtocol`]s
1532//!
1633//! Currently supports
1734//! - proof of knowledge of a BBS+ signature and signed messages
3855//! message satisfies some upper and lower bounds i.e. min <= signed message <= max. This is a range proof.
3956//! - test `pok_of_bbs_plus_sig_and_verifiable_encryption` shows how to verifiably encrypt a message signed with BBS+ such
4057//! that the verifier cannot decrypt it but still ensure that it is encrypted correctly for the specified decryptor.
58+ //! - test `pok_of_bbs_plus_sig_with_reusing_setup_params` shows proving knowledge of several BBS+ signatures
59+ //! using [`SetupParams`]s. Here the same signers are used in multiple signatures thus their public params
60+ //! can be put as a variant of enum [`SetupParams`]. Similarly test
61+ //! `pok_of_knowledge_in_pedersen_commitment_and_equality_with_commitment_key_reuse` shows use of [`SetupParams`]
62+ //! when the same commitment key is reused in several commitments and test `pok_of_bbs_plus_sig_and_verifiable_encryption_of_many_messages`
63+ //! shows use of [`SetupParams`] when several messages are used in verifiable encryption for the same decryptor.
4164//!
4265//! *Note*: This design is largely inspired from my work at Hyperledger Ursa.
4366//!
4467//! *Note*: The design is tentative and will likely change as more protocols are integrated.
4568//!
4669//! [`Statement`]: crate::statement::Statement
4770//! [`MetaStatement`]: crate::meta_statement::MetaStatement
71+ //! [`SaverProver`]: crate::statement::saver::SaverProver
72+ //! [`SaverVerifier`]: crate::statement::saver::SaverVerifier
73+ //! [`SetupParams`]: crate::setup_params::SetupParams
4874//! [`ProofSpec`]: crate::proof_spec::ProofSpec
4975//! [`Witness`]: crate::witness::Witness
5076//! [`StatementProof`]: crate::statement_proof::StatementProof
5177//! [`Proof`]: crate::proof::Proof
5278//! [`SubProtocol`]: crate::sub_protocols::SubProtocol
79+ //! [`SaverProtocol`]: crate::sub_protocols::saver::SaverProtocol
80+ //! [`SchnorrProtocol`]: crate::sub_protocols::schnorr::SchnorrProtocol
5381
5482extern crate core;
5583
@@ -75,6 +103,6 @@ pub mod prelude {
75103 pub use crate :: setup_params:: * ;
76104 pub use crate :: statement:: * ;
77105 pub use crate :: statement_proof:: * ;
78- pub use crate :: sub_protocols:: * ;
106+ pub use crate :: sub_protocols:: bound_check_legogroth16 :: generate_snark_srs_bound_check ;
79107 pub use crate :: witness:: * ;
80108}
0 commit comments