[][src]Module bulletproofs::aggregation

The aggregation module contains the API for performing the aggregated multiparty computation protocol.

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.