4

The STARKs paper states

Third, and most important, ZK-PCPs are transparent (or “public randomness” ), which means that the randomness used by the verifier is public; in particular, setting up a ZK-PCP requires no external trusted setup phase

as one of its main advantages over SNARKs. This statement is not fully clear to me. Which properties rely on this "common random string"? Does the verifier only "trust" a received proof if he/she trusts that the public random string was chosen uniformly at random? If not, why can't the prover simply pick a random string itself and send it along with the proof if the setup does not need to be trusted? This way there would be no setup at all.

Cryptonaut
  • 1,066
  • 7
  • 19

1 Answers1

3

That is a very good question. First, observe that in general, using a common random string (or any other form of trusted setup) is necessary to get any provable security guarantee, as soon as you want your proof system to handle statements outside of BPP. Indeed, it is known that non-interactive zero-knowledge proofs without any trusted setup can only exist for languages in BPP.

So, it is necessarily the case that "something" relies on the common reference string being sampled at random, in a trusted way. That "something" can be either soundness, zero-knowledge, or both (since those are the two security properties we care about). With most existing proof systems, the crs is actually needed for both:

  • if the prover picks the string himself, he can break the soundness of the proof (i.e., prove incorrect statements)
  • if the verifier picks the string himself, he can break the zero-knowledge property of the proof.

Whether this issue can be mitigated has been studied under the name of subversion resistance. This is a line of work which attemps to build NIZKs/SNARGs that maintain some security guarantees even if the common reference string is adversarially subverted. It was initiated in this paper. Essentialle, it shows that achieving zero-knowledge and preserving soundness under subversion at the same time is impossible - however, the other way around is possible. Several follow-ups (1, 2) have built various subversion-resistant SNARGs.

The transparent setup of STARKs avoid this issue essentially by relying on the Fiat-Shamir transform; in the random oracle model, it is in fact possible to have NIZKs without setup for arbitrary languages, so that's just what they do (succinctly). Of course, in the end, their non-interactive argument has no provable security guarantee in the plain model, but only heuristic security guarantees given by the analysis in the ROM.

So to conclude:

  • Standard SNARGs: you need to perform a trusted setup or find a globally verifiable source of randomness which is hard to manipulate (e.g. the result of the last 100 loteries, or randomness extracted from black spots on the sun, or whatever you like - to be honest, any nothing-up-my-sleeve number should work in practice, so you can just take the digits of Pi). But in exchange for that, they can be proven secure under some (non-standard) assumption, in the standard model.
  • STARKs: no trusted setup, you have a provably secure construction, but only in an idealized model with a random oracle. This gives you something heuristically secure, but with no formal security argument, when you replace the random oracle with a true hash function. However, it removes the burden of finding a source of globally verifiable randomness.
Geoffroy Couteau
  • 19,919
  • 2
  • 46
  • 68
  • Thanks for the elaborate answer! I just got very confused by the "transparent setup" statement in their paper, since I have never seen it in any other paper and I don't really understand why they didn't simply say that they don't require a setup instead of calling it transparent. Thanks anyways! – Cryptonaut Mar 19 '19 at 18:40
  • When no one satisfies a given property, no one gives it a name - but when you claim to be the first to achieve it, you name it, it makes it easier to clearly state your improvement :) – Geoffroy Couteau Mar 19 '19 at 18:55
  • I mean without knowing the details it sounds like it's either just a public-coin zero-knowledge argument or a sigma protocol? That we already had before and these things have names :) – Cryptonaut Mar 19 '19 at 20:38
  • yep, that's what it is, but succinct, concretely efficient, and post quantum. That, we did not have. – Geoffroy Couteau Mar 19 '19 at 21:15
  • fair enough. Thanks a lot for the clarification! – Cryptonaut Mar 19 '19 at 22:59
  • One of your claims is incorrect. zk-STARKs require verifiable public randomness (aka cryptographic entropy) as input for the setup process. The random oracle model does not generate entropy. – Shelby Moore III Oct 11 '23 at 15:26
  • No, my claim is not incorrect. Turning an IOP into a STARK requires only the ROM, no common random string. I would advise against making strong claims based on the high-level description you found on the Ethereum website: instead, you can check the paper, the formal constructions, and their analysis. Also, your link --about the ROM not generating entropy-- does not mention the ROM and seems unrelated. In the ROM, H(1), H(2), ..., H(n) is a truly random string of arbitrary length. This is, well, the definition of what the ROM is. – Geoffroy Couteau Oct 11 '23 at 20:33
  • @GeoffroyCouteau randomization (ROM) ≠ cryptographic entropy. §3.3 confirms only a public random beacon (e.g. Bitcoin) disavows their (dubious, unproven) “stronger” cryptographic assumptions. You tread quixotically on such magical assumptions that afaics would violate the fundamental ‘bounded’ tenet of NIZKPs. C.f. followup… – Shelby Moore III Oct 12 '23 at 06:40
  • …so I guess I’m suggesting that an attack on zk-STARK (not STARK w/o secret inputs to the proven circuit) should be theoretically possible if cryptographic entropy isn’t employed by the verifier. zk-SNARK transfers an interactive requirement to the setup stage, yet they’re still interactive in that they require publicly validated cryptographic entropy. I highly doubt that zk-STARKs can obviate what appears to be a fundamental bound/invariant. Do you have reason to think otherwise? Ty for replies. – Shelby Moore III Oct 12 '23 at 06:55
  • Per my source, a fundamental tenet is that trusting the verifier to select the randomness can leak the zero-knowledge. If that turns out to be the case, then it’s not secure to trust the prover (acting as the verifier via the Fiat-Shamir transform) to employ cryptographic entropy. Do you have any sources which have studied this facet? – Shelby Moore III Oct 12 '23 at 07:35
  • I am honestly puzzled by the fact that you are making claims and citing sources that seem totally unrelated to your claims. It seems there are many fundamental misunderstandings on your side, I'm not sure I can address them all in a comment section. First, "ROM" is not "randomization". The ROM is an idealized model where all parties are given oracle access to a truly random function. Saying "randomization (ROM) [...]" seems to imply that you don't know that we are talking about an idealized model, something that does not exist in the real world. Is this the part of my claim that you missed? – Geoffroy Couteau Oct 12 '23 at 07:40
  • (see: "STARKs: no trusted setup, you have a provably secure construction, but only in an idealized model with a random oracle") Second, yes, in the real world, a NIZK provably requires a common random string. This is well known since the 90s, and I never claimed anything to the contrary. You "dubious, unproven" link seems to have absolutely nothing to do with that, but that's still true nonetheless and I never said otherwise. – Geoffroy Couteau Oct 12 '23 at 07:42
  • Third, your source saying that trusting the verifier to select the randomness can leak the zero-knowledge is wrong in general. There exists zero-knowledge proofs which are zero-knowledge even when the verifier picks their randomness - that's, in fact, part of the definition of "zero-knowledge". When it's not satisfied, it's called "honest-verifier zero-knowledge". IOP are HVZK, but compiling them into NIZKs via Fiat-Shamir makes them truly ZK in the ROM (again, not the real world) – Geoffroy Couteau Oct 12 '23 at 07:44
  • Last, "If that turns out to be the case, then it’s not secure to trust the prover (acting as the verifier via the Fiat-Shamir transform) to employ cryptographic entropy." This sentence makes no sense. You are confusing zero-knowledge (what a cheating verifier attacks) and soundness (what a cheating prover attacks). The way the prover "acts as a verifier" in the ROM does not involve "employ[ing] cryptographic entropy", but only hashing the transcript with a RO – Geoffroy Couteau Oct 12 '23 at 07:46
  • @GeoffroyCouteau strawman. Steelman my points for progress on mutual agreement. I obviously know that ROM means an idealized model for randomization. I hope you understand that is not cryptographic entropy: “uncertainty an attacker faces to predict the randomness.” Do you even understand the distinction between trustless publicly validated cryptographic entropy and trusted sources of cryptographic entropy? You need to do more to convince me you are the expert here. – Shelby Moore III Oct 12 '23 at 07:49
  • Let us continue this discussion in chat. – Geoffroy Couteau Oct 12 '23 at 07:51
  • Ty for chat invite. I’ll make one more public comment first after seeing your followups. ROM repeats same output for same input, thus by definition can’t provide cryptographic entropy. Thus even as considered in ROM, my points still apply. You claim that NIZK exists without requirement for cryptographic entropy in violation of the cited historical fundamentals, but the only example you cite is the one my “dubious, unproven” source states the “stronger assumptions” are unproven. Trustless cryptographic entropy is not even created by proofs-of-work alone. – Shelby Moore III Oct 12 '23 at 08:04
  • Also what you claim is my nonsense confusion about the role of the Fiat-Shamir transform is ostensibly your (what appears to me to be your inkblot in) equating ROM to true “randomization” in the cryptographic entropy sense. Idealized ROM does present a uniform distribution from input to output but because of its repeatability doesn’t prevent the prover from potentially biasing the output of the ROM by running it first before committing. Computational intractability can for example sometimes be violated by biasing a single bit which can potentially aid the verifier in leaking zero knowledge. – Shelby Moore III Oct 12 '23 at 08:26