Attach auth_length to AuthPath and SRS

[burdges]

At present, our circuit needs its auth_path to be length auth_depth, which I suppose avoids adding logical constraints that permit stopping early. How bad would such constraints be? Should we just publish a series of SRSs for different sizes? How deep does zcash's SRS support?

If otoh we keep the full length AuthPath, then we should reevaluate everywhere we pass Params because the AuthPath's length determines this too. We should of course ensure our main JubJub generator does not overlap with any generators used by Pedersen hashes if we select our SRS based on the AuthPath's length. lol

[swasilyev]

I'm not sure if i understand. The prover performance for a circuit is always worst-case. So by supporting smaller depth we just save some negligible computations outside the snark. Also the circuit, i guess, would grow 2x, by adding a conditional at each tree level.

[burdges]

In that case, we should publish a series of SRSs for different sizes I suppose. I think the SRS and AuthPath should identify auth_length and the AuthPath should identify the root, from which it checks the PublicKey for #4. I've renamed this issue.

[swasilyev]

That really depends on how we promote the SRS. If we still avoid many-participant MPC for the circuit-specific part of the setup, I would start with an SRS that supports the ring we need. For general use I would propose using the circuit with some circuit-agnostic (updatable-universal) setup, like Marlin. I will test it, after Zexe implementation of the circuit is ready.

[burdges]

We're only talking about groth16 here :) Anything like marlin waits for another day. At this point
all mathematical questions appeared answered so this issue only concerns the interface.

[swasilyev]

I think I am wrong that circuit size would duplicate. It depends on the implementation. Anyway I don't see how it could be useful.