Although we are not implementing the SNARK circuit at the moment, we should make sure that we're using a hash function that is SNARK-friendly enough, so that we can batch multiple epochs.
It seems we require around 800 bits of output. They way we achieve it at the moment, when using a 256 bit output, is:
Hashing the message with a Pedersen hash, which is only collision-resistant.
Hashing that resulting message 4 times with SHA256 and an incrementing nonce in front of the message, such that we have 1024 random-looking bits.
Some possibilities:
What we have now - Pedersen hash over Edwards/SW6 as defined in ZEXE.
Rescue/Poseidon - new hash functions from this year, which are very SNARK-friendly.
Blake2s/Blake2b/SHA512/SHA3 - SNARK-costly hash functions which mostly vary by their output size and their SNARK cost. We know the cost of Blake2s and SHA256, which output 256 bits. We'll have to evaluate this case-by-case and see if others have done this work in the past.
MiMC, which has received some, though still little attention. Very SNARK-friendly.
Although we are not implementing the SNARK circuit at the moment, we should make sure that we're using a hash function that is SNARK-friendly enough, so that we can batch multiple epochs.
It seems we require around 800 bits of output. They way we achieve it at the moment, when using a 256 bit output, is:
Some possibilities: