Breakout Session: Structured Reference String Generation

2nd ZKProof Workshop
1

Abstract: Non-Interactive Zero-knowledge proofs and arguments require a common reference string known to all parties. Common reference strings with structure are termed structured reference strings. Currently we are unaware of methods to generate structured reference strings without the use of trusted third parties. In this session we shall discuss best practice for distributing the generation of structured reference strings. We shall discuss both MPC and updatable techniques.

1 Like
2

Scribe: Ariel Gabizon

2nd ZKProof Workshop Notes

Objectives/thoughts:

  • Call it decentralized setup instead of “trustless setup”?

  • Size of the SRS (try to keep it small because users need to download it) In Zcash - having crs small enough for passing around in DVD.

  • Can we have an update process where updates can be done in parallel?

Important e.g. if several people try to update same state in similar time

  • Is there a point in more than 128 parties for 128 bit security if each person is honest w.p ½
  • Experiment: distribute Ether amongst 40 parties to see practical capability of attacking many parties simultaneously - though perhaps hard to simulate an experiment with similar reward.
  • Model: not all participants are online at once. Stronger than having everyone online for multiple rounds.
  • Will people stop participating at some point?
  • Will there be a DOS attack when too many people try to update at once
  • Making sure the person requesting to participate is not forever delayed by the organizer (is the organizer subverting the process by selecting participants)?
  • Focus on building a public SRS that would be publicly used. How do we build this? Build for different curves, circuit sizes, etc.
  • How do we handle Sybils in such a process (there should be posts to twitter, attestations of contributions by reputable individuals, etc.)
  • Which MPC we use, what are the update proofs, don’t suggest best practices for filtering people.
  • Diversity of hardware – have some record of what is used (software versions, hardware, etc.)
  • Can the updatable SRS generated suffice for smaller circuits. Proofs of well formed updates in Sonic can be read only for monomials that are relevant for the circuit size.
  • Updatable and non-updatable SRS generation.
  • Who are the participants? what is the attack model? What are security assumptions? What’s the ideal functionality?
  • Ideal functionalities vs. “Code based games” approach for security. For sapling: Showing that if an attacker corrupted the SRS, he would have also succeeded in doing something similar in a trusted setup SRS.
2 Likes
3

small credit fix: scribed together with Aviv Zohar

1 Like
4

Hi @mmaller and @arielg were there specific contributions or action items that derived from this discussion? I could suggest some:

  • looking at the reference document I would say it is missing a proper explanation of updateability / universality, its implications and potentially a description on how to achieve this (maybe the latter should go in the security section)
  • A more specific explanation on how to proceed with an MPC (without getting into details of the construction), but detailing the practical needs to make it happen.
  • probably more stuff