-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Poseidon circuit #21
Comments
Just to recap. We have a garbling scheme BMR16 already implemented in Rust here https://github.com/GaloisInc/swanky/tree/master/fancy-garbling
We are looking for a snark-friendly hash which fits all those criteria. |
in the BMR16 paper Figure 3 (p.16) shows that for 64-bit numbers exponentiation-by-constant gate costs 365*16=~5KB. Usually in zksnarks we deal with 256-bit numbers, so we can extrapolate that it will cost ~30KB to exponentiate a 256-bit number. Edit: Poseidon hashes 16 field elements (of 31 bytes each), not 16 bytes. Fixed numbers accordingly. It takes 204 exponentiations to hash 16*31=496 bytes of data with vanilla Poseidon. That's gonna cost us (204 * 30) / 496 * 16 = ~200KB of bandwidth per 16 bytes of plaintext. Not ideal but a starting reference point. |
Oh, just realized that have some kind of "golden poseidon". It operates on 64-bit fields (i guess that's the new field from plonky2). |
Closing this issue as we determined that Poseidon can't viably be computed with a boolean circuit, and the BMR16 scheme does not support constant cost exponentiation by a prime. We're instead pursuing another technique to generate Poseidon commitments using a combination of garbled circuits and SNARK |
Regarding our recent discussion to produce SNARK-friendly hashes of the query and response data using 2PC, we'll need to produce the boolean circuits for Poseidon.
The text was updated successfully, but these errors were encountered: