Add a switch to enable/disable instance hashing

[AntoineRondelet]

Recently, Zeth has been updated to support hashing the instance - which allows to break the linear complexity of the Snark verifier, which is ultimately required to improve the "generic" aspect of Zecale. However, the associated extra operations (on the C++ side and on the Solidity side) are not necessarily desired if Zeth is used in a standalone way. Hence, it would be nice to decide which variant to use at compile time in order to produce the appropriate binary (for use via Zecale, or in a standalone way).

[AntoineRondelet]

That'd be nice to find a reasonable approach to keep support for "standalone" Zeth while supporting aggregation via Zecale (in the current state of the code base, we don't support "standalone" Zeth anymore as we baked the Zecale integration to the code without "switches")

So here's an initial list of what's needed - but let's discuss further:

• Change the signature of the smart contract functions to make sure that an array of primary inputs can be passed (and not only 1 uint256 corresponding to the hashed instance). While we can generalize existing functions to support arrays as input, we can also refine the contract's structure and simply add new functions for the zecale integration (with their own signatures) if this is more efficient (i.e. incurs less overhead)
• Add some flags to the python and c++ code to activate/de-activate instance hashing etc
• Maybe add some compilation configuration flags to compile the project in "standalone" or "aggregated" (i.e. zecale) mode - or maybe just flags to the "prover" executable?

Note: if we want two entry points to the same Zeth contract on-chain for the "standalone" and the "aggregated" mode (which is desirable as it keeps 1 unique anonymity set), we also need to be able to verify proofs with 2 vks since the zeth statement is modified to integrate with Zecale. Hence we also need to modify the storage variables of the Mixer (to have a _vk_standalone and _vk_aggregated) etc. and call verifyZkp with the appropriate vk depending on the smart contract entry point (i.e. dispatch vs (vanilla) mix)

@dtebbs - thoughts?

[dtebbs]

If I've uderstood the issue here, the switch would only control whether to use the GGPR trick so that verification uses a single scalar multiplication, or requires a multiplication per public element. The "standalone" terminology (which just implies operation outside of zecale) vs "aggregated" (implying operating via some batching mechanism) may be confusing (for example, we currently support "standalone" mode, we just use GGPR to make verifcation more efficient).

I may have forgotten / missed something, but given the extra complexity involved, it's not obvious to me where the need to support standalone without GGPR comes from. (Note that zeth always works in standalone mode, with other flags that enable/disable the delegated verifier.) Supporting both modes (with and without the GGPR trick) side-by-side seems especially like it would involve even further complexity which may be diffcult to justify (multiple circuits in the prover, multiple request / response types, keeping multiple keys in the contract).

AFAICT (and this is where I'm probably missing something) the only benefit is a small constraint saving in the circuit. We could do the measurement (in fact, it should be straightforward to calculate), but would this alone justify the increase in gas cost and complexity?

[AntoineRondelet]

If I've uderstood the issue here, the switch would only control whether to use the GGPR trick so that verification uses a single scalar multiplication, or requires a multiplication per public element. The "standalone" terminology (which just implies operation outside of zecale) vs "aggregated" (implying operating via some batching mechanism) may be confusing (for example, we currently support "standalone" mode, we just use GGPR to make verifcation more efficient).

Sure, we can definitely revise the terminology - what I mean here is "standalone Zeth = Zeth used without Zecale" and "aggregated Zeth = Zeth with Zecale" :)
The point is pretty much what I said in the ticket description, i.e.

However, the associated extra operations (on the C++ side and on the Solidity side) are not necessarily desired if Zeth is used in a standalone way. Hence, it would be nice to decide which variant to use at compile time in order to produce the appropriate binary (for use via Zecale, or in a standalone way).

Sure, we can still use the instance hashing to use Zeth "standalone" - but the reason this was introduced is mostly because of Zecale (to break the linear complexity of the verifier). Of course, it may still be viable to keep this instance hashing if Zeth is used without Zecale, but you're right when you say:

We could do the measurement (in fact, it should be straightforward to calculate), but would this alone justify the increase in gas cost and complexity?

Definitely. To properly spot the costs and make the appropriate tradeoffs, we should measure the overhead of the instance hashing (if any) to see if we would like to remove it for the "standalone mode" or if it makes sense to remove it (e.g. we save scalar mults on the verifier but we pay extra hashing cost in the circuit + pay extra for the additional instance hash to pass to the CALLDATA, the hash check on the contract etc)