Possibility of using SNARKs instead of STARKs

[jinankjain]

Hi guys,

Really great project. So I was going through the code and according to my understanding it should be possible to swap the current zkp module from using STARKs to SNARKs. Is there any assumptions on zkvm side which would stop me in doing that?

[intoverflow]

Is there any assumptions on zkvm side which would stop me in doing that?

The ZKVM implements a STARK prover, so if you did want to switch to a SNARK backend, you'd basically need to rewrite some significant portion of the repo.

[jbruestle]

So technically, the ZKVM 'circuit' and the ZKP proof system are separate pieces of code with a light abstraction between them. Theoretically, it would be possible to translate the few STARK specific bits of the abstraction (like rows + taps) automatically to an unrolled set of SNARK element + constraints. In fact, as I'm working on the next version of the circuit compiler, I do plan to consider more specific support for translation to SNARKs, but I think we should leave the ticket closed, since I don't think it makes sense to do at this time.

[jinankjain]

Thanks @jbruestle for the explanation. I was expecting exactly what you are saying. It is great to hear that you are thinking about SNARK compatibility in the future version of the compiler. Let me know if I can help you guys out on that front. Any motivation on choosing STARK over SNARKs for your project. STARKs are known to have larger proof size as compared SNARKs right?

[jbruestle]

ZkStarks have much faster proving time for repetitive circuits like a VM (although SNARKs have improved). Additionally STARK are post quantum if you happen to care, and in fact our protocols only cryptographic operation that doesn’t have a full proof in the random oracle model is SHA256. Finally at the time, most common SNARK systems required trusted setup.