Today we are going to go diving into the zk-SNARKs Setup Phase. As we mention some days ago, anyone who deploys a zk-SNARK circuit to production must perform a computation called a trusted setup in order to generate a proving key and verifying key. Unfortunately, this process also produces a piece of data called toxic waste which must be discarded, as it can be used to produce fake proofs and thereby violate the security of the system.
This requires that both the prover and verifier have access to some common knowledge, usually encoded in a Common Reference String (CRS) or Structured Reference String (SRS), a way of saying that the proving and verification keys are generated by the same setup algorithm, and are mostly the same.
In our example, we use circom and snarkjs.
But, why is groth16 so great?
So what is the problem with a trusted setup? The balance between privacy for the prover and assurance of not cheating for the verifier is delicate. Having one single entity generate the keys sort of defeats the purpose of using zero-knowledge proofs in the first place, at least in public systems where everyone is a prover and a verifier. This is exactly why SNARKs that have a structured setup phase are best coupled with a multiparty computation (MPC) for the setup, to reduce the trust assumptions. Ideally, such an MPC involves a large number of parties, and ensures that even if merely any one of the parties behaves honestly and erases their own local secrets, then the result is secure. Put otherwise, security holds unless all parties are malicious or compromised.
That's all for this thread. Next week we are going to talk about ZKP without a trustep setup. Thank you for reading! If you liked, follow me @Hasseru and retweet.