Module bulletproofs::range_proof_mpc

The range_proof_mpc module contains the API for performing the aggregated multiparty computation protocol for joint range proof proving.

Only the range proofs are supported, while aggregation of constraint system proofs is under development.

API for the aggregated multiparty computation protocol

To create the aggregated range proof, \(m\) individual parties which each have a secret value exchange messages with one dealer, which does not know their secret values. The protocol to create an aggregated range proof can be run locally or across a network. The protocol should use this API to manage the party states (see party module), dealer states (see dealer module), and messages (see messages module).

First, \(m\) Party objects are instantiated with their secret values and the range for the range proof. A Dealer object is instantiated with \(n\) and \(m\). The dealer assigns a unique index \(j\) to each party.

Next, each Party commits to their secret value, bits, and blinding factors via \(V_{(j)}, A_{(j)}, S_{(j)}\) and sends this data in a BitCommitment to the dealer. The dealer receives and combines all of the BitCommitment messages from all of the parties, generates challenges \(y, z\), and sends \(y, z\) as BitChallenge to all of the parties.

Then, each party commits to the resulting polynomials via \(T_{1, (j)}, T_{2, (j)}\) and sends this data in a PolyCommitment to the dealer. The dealer receives and combines all of the PolyCommitment messages from all of the parties, generates challenge \(x\), and sends \(x\) as PolyChallenge to all of the parties.

Finally, each party evaluates their polynomial at \(x\) and returns the result as ProofShare to the dealer. The dealer combines all \(m\) ProofShare messages and returns the aggregated range proof, RangeProof.

Party and Dealer state machines

We wanted a foolproof model that would prevent users from performing any step other than the correct next step of the protocol. In our implementation, we treated each party and dealer as a state machine, and modeled each party and dealer state as a distinct type. We used move semantics to ensure that a previous state is consumed as it transitions to the next state.

Due to the type system, we have a guarantee that one step of the protocol can't be performed twice, since the first function call for that step would consume the object, and therefore the function would not be able to be called on that object another time. We also have a guarantee that the user can't perform steps out of order or skip steps, since it is impossible to call a function on an object that is not of the correct corresponding type.

Modules

dealer	The dealer module contains the API for the dealer state while the dealer is engaging in an aggregated multiparty computation protocol.
messages	The messages module contains the API for the messages passed between the parties and the dealer in an aggregated multiparty computation protocol.
party	The party module contains the API for the party state while the party is engaging in an aggregated multiparty computation protocol.

Enums

MPCError

Represents an error during the multiparty computation protocol for proof aggregation.