If a user cannot generate a proof locally for a large circuit in SNARK in his phone or browser, he can delegate it to a server. However, he has to tell the witness to the server(s), which violates the zero-knowledge property of SNARK. What is the state of the art for delegating proof generation without disclosing the witness? I find this work and Trinocchio, which assumes at least T out of N servers are honest.
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
You can sometimes partition the witness into a part that needs the full generality of a zk proof system, and a part consisting just of private keys that the prover must demonstrate that they know. Then, the zk proof can be provided together with a set of signatures by those private keys, so that they do not need to be accessible to the delegated prover. The keys must be randomised to avoid giving away which keys were used, but the proof is able to constrain the original key(s) to make sure it/they are the right one(s).
Zcash uses this technique to allow creating transactions using hardware wallets that would not be able to generate a proof (see sections 4.15 and 4.1.7.1 of the Zcash protocol spec), where only the hardware wallet knows the spending keys. Unlike more general multi-party proving techniques, it has only a small fixed overhead: the randomization of a public signing key in the circuit only requires one fixed-base scalar multiplication. The downside is that you're still revealing part of the witness to the delegated prover.
