Skip to content

Commit 79bdebb

Browse files
loveshlovesh
committed
Update Readme
Signed-off-by: lovesh <lovesh.bond@gmail.com>
1 parent 98abf75 commit 79bdebb

File tree

1 file changed

+76
-5
lines changed

1 file changed

+76
-5
lines changed

‎proof_system/README.md‎

Lines changed: 76 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1,17 +1,19 @@
1-
# Composite Proof System
1+
# proof_system
22

33
The goal of this crate is to allow creating and combining zero knowledge proofs by executing several
44
protocols as sub-protocols.
5+
56
The idea is to represent each relation to be proved as a [`Statement`], and any relations between
67
[`Statement`]s as a [`MetaStatement`]. Both of these types contain public (known to both prover
78
and verifier) information and are contained in a [`ProofSpec`] whose goal is to unambiguously
89
define what needs to be proven. Some [`Statement`]s are specific to either the prover or the verifier
910
as those protocols require prover and verifier to use different public parameters. An example is Groth16
1011
based SNARK protocols where the prover needs to have a proving key and the verifier needs to
1112
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+
they don't need to. Thus for such protocols, there are different [`Statement`]s for prover and verifier,
1314
like [`SaverProver`] and [`SaverVerifier`] are statements for prover and verifier respectively,
1415
executing SAVER protocol.
16+
1517
Several [`Statement`]s might need same public parameters like proving knowledge of several BBS+
1618
from the same signer, or verifiable encryption of several messages for the same decryptor. Its not
1719
very efficient to pass the same parameters to each [`Statement`] especially when using this code's WASM
@@ -20,6 +22,67 @@ put all such public parameters as [`SetupParams`] in an array and then reference
2022
while creating an [`Statement`]. This array of [`SetupParams`] is then included in the [`ProofSpec`]
2123
and used by the prover and verifier during proof creation and verification respectively.
2224

25+
A common requirement is to prove equality of certain [`Witness`]s of certain [`Statement`](s). This
26+
is done by using the [`EqualWitnesses`] meta-statement. For each set of [`Witness`]s (from the same or different [`Statement`]s)
27+
that need to proven equal, a [`EqualWitnesses`] is created which is a set of witness references [`WitnessRef`].
28+
Each [`WitnessRef`] contains the [`Statement`] index and the [`Witness`] index in that [`Statement`] and
29+
thus uniquely identifies any [`Witness`] across [`Statement`]s. The [`EqualWitnesses`] meta-statement is also
30+
used to prove predicates over signed messages in zero knowledge, when doing a range-proof over a
31+
signed message (using BBS+), the [`EqualWitnesses`] will refer [`Witness`]s from `Statement::PoKBBSSignatureG1`
32+
statement and `Statement::BoundCheckLegoGroth16` statement. Following are some illustrations of [`EqualWitnesses`]
33+
34+
┌────────────────────────────┐ ┌──────────────────────────────┐ ┌────────────────────────────┐
35+
│ PokBBSSignatureG1 │ │ PokBBSSignatureG1 │ │ PokBBSSignatureG1 │
36+
│ Statement 1 │ │ Statement 2 │ │ Statement 3 │
37+
├────────────────────────────┤ ├──────────────────────────────┤ ├────────────────────────────┤
38+
│ A1, A2, A3, A4, A5 │ │ B1, B2, B3, B4 │ │ C1, C2, C3, C4, C5, C6 │
39+
└─────────▲──────────────────┘ └─────▲────────▲───────────────┘ └─▲────────────────▲─────────┘
40+
│ │ │ │ │
41+
│ │ │ │ │
42+
│ │ │ │ │
43+
│ │ │ │ │
44+
│ ┌-───────────────┴────────┴───┬───────────────────┼──────┬─────────┴──────────────────┐
45+
└────────────┼(0, 2), (1, 1), (2, 0) ├───────────────────┘ │ (2, 3), (3, 4) │
46+
├-────────────────────────────┤ ├────────────────────────────┤
47+
│ EqualWitnesses │ │ EqualWitnesses │
48+
│ MetaStatement 1 │ │ MetaStatement 2 │
49+
│ A3, B2 and C1 are equal │ │ B4 and C5 are equal │
50+
└─────────────────────────────┘ └────────────────────────────┘
51+
52+
For proving certain messages from 3 BBS+ signatures are equal. Here there 2 sets of equalities,
53+
1. message A3 from 1st signature, B2 from 2nd signature and C1 from 3rd signature
54+
2. message B4 from 2nd signature and C5 from 3rd signature
55+
56+
Thus 3 statements, one for each signature, and 2 meta statements, one for each equality
57+
---------------------------------------------------------------------------------------------------------------------------------------------------
58+
59+
┌────────────────────────────┐ ┌──────────────────────────────┐ ┌────────────────────────────┐
60+
│ PokBBSSignatureG1 │ │ BoundCheckLegoGroth16 │ │ SAVER │
61+
│ Statement 1 │ │ Statement 2 │ │ Statement 3 │
62+
├────────────────────────────┤ ├──────────────────────────────┤ ├────────────────────────────┤
63+
│ A1, A2, A3, A4, A5 │ │ B1 │ │ C1 │
64+
└─────────▲───────▲──────────┘ └─────▲────────-───────────────┘ └───────────────▲────-───────┘
65+
│ |─────────────────| │ │
66+
│ | │ │
67+
│ |──-│-────────────────────| │
68+
│ │ | |───|
69+
│ ┌-───────────────┴────────-───┬────────|───────────────────────────-|─────────────────┐
70+
└────────────┼(0, 2), (1, 0) | |─────────────────│── (0, 4), (2, 1) │
71+
├-────────────────────────────┤ ├────────────────────────────┤
72+
│ EqualWitnesses │ │ EqualWitnesses │
73+
│ MetaStatement 1 │ │ MetaStatement 2 │
74+
│ A3 and B1 are equal │ │ A5 and C1 are equal │
75+
└─────────────────────────────┘ └────────────────────────────┘
76+
77+
78+
For proving certain messages from a BBS+ signature satisfy 2 predicates,
79+
1) message A3 satisfies bounds specified in statement 2
80+
2) message A5 has been verifiably encrypted as per statement 3.
81+
82+
Thus 3 statements, one for a signature, and one each for a predicate. 2 meta statements, one each
83+
for proving equality of the message of the signature and the witness of the predicate
84+
--------------------------------------------------------------------------------------------------------------------------------
85+
2386
After creating the [`ProofSpec`], the prover uses a [`Witness`] per [`Statement`] and creates a
2487
corresponding [`StatementProof`]. All [`StatementProof`]s are grouped together in a [`Proof`].
2588
The verifier also creates its [`ProofSpec`] and uses it to verify the given proof. Currently it is
@@ -37,8 +100,11 @@ Currently supports
37100
- proof of knowledge of Pedersen commitment opening.
38101
- proof of knowledge of BBS+ signature(s) and that certain message(s) satisfy given bounds (range proof)
39102
- verifiable encryption of messages in a BBS+ signature
40-
- proof of knowledge of BBS+ signature(s) and that certain message(s) satisfy given R1CS. The R1CS is generated from programs
41-
written in [Circom](https://github.com/iden3/circom) version 2.
103+
- proof of knowledge of BBS+ signature(s) and that certain message(s) satisfy given R1CS. The R1CS is generated
104+
from [Circom](https://github.com/iden3/circom) and the proof system used is [LegoGroth16](https://github.com/lovesh/legogro16).
105+
LegoGroth16 is similar to Groth16 but in addition to the zero knowledge proof, it provides a Pedersen
106+
commitment to the witness (signed messages in our case). This commitment allows us to prove that the witness in
107+
the proof protocol are the same as the signed messages using the Schnorr proof of knowledge protocol.
42108

43109
See following tests for examples:
44110

@@ -63,14 +129,19 @@ See following tests for examples:
63129
`pok_of_knowledge_in_pedersen_commitment_and_equality_with_commitment_key_reuse` shows use of [`SetupParams`]
64130
when the same commitment key is reused in several commitments and test `pok_of_bbs_plus_sig_and_verifiable_encryption_of_many_messages`
65131
shows use of [`SetupParams`] when several messages are used in verifiable encryption for the same decryptor.
66-
-
132+
- For R1CS/Circom, see various tests like using less than, not-equals comparison operators on messages signed with BBS+, proving
133+
that the preimage of an MiMC hash is the message signed with BBS+, sum of certain signed messages (from same or different signatures)
134+
is bounded by a given value, etc [here](tests/r1cs). The Circom compiler output and circuits are [here](tests/r1cs/circom).
135+
The circuits were compiled and tested for BLS12-381 curve.
67136

68137
*Note*: This design is largely inspired from my work at Hyperledger Ursa.
69138

70139
*Note*: The design is tentative and will likely change as more protocols are integrated.
71140

72141
[`Statement`]: crate::statement::Statement
73142
[`MetaStatement`]: crate::meta_statement::MetaStatement
143+
[`EqualWitnesses`]: crate::meta_statement::EqualWitnesses
144+
[`WitnessRef`]: crate::meta_statement::WitnessRef
74145
[`SaverProver`]: crate::statement::saver::SaverProver
75146
[`SaverVerifier`]: crate::statement::saver::SaverVerifier
76147
[`SetupParams`]: crate::setup_params::SetupParams

0 commit comments

Comments
 (0)