The Groth 16 paper reduces the number of pairings from 8 to 3, so that should reduce the gas cost of withdrawals by ~2x.

[barryWhiteHat]

https://github.com/scipr-lab/libsnark/tree/92a80f74727091fdc40e6021dc42e9f6b67d5176/libsnark/zk_proof_systems/ppzksnark/r1cs_gg_ppzksnark

[barryWhiteHat]

Our friends @ ZoKrates are working on this Zokrates/ZoKrates@develop...Schaeff:implement-groth16

[davidp94]

there are other new curves that could reduce the number of constraints. https://drive.google.com/file/d/13roNjz5mXF6c7OvJM_FvOl6pditVL0f-/view

…

On Fri 22 Jun 2018 at 15:55 barryWhiteHat ***@***.***> wrote: Our friends @ ZoKrates are working on this JacobEberhardt/ZoKrates@ develop...Schaeff:implement-groth16 <Zokrates/ZoKrates@develop...Schaeff:implement-groth16> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#20 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AYtbNU4lCxP6glm3FWgeiEtOXZTIATqBks5t_QVVgaJpZM4Uz69I> .

[barryWhiteHat]

@davidp94 the number of constraints is only a factor when you want to optimize proving time. The verification time is constant regardless of the number of constraints.

That said currently the proving time is 7 minutes on a laptop. so right now mobile i pretty much excluded unless we reduce the number of constraints.

[HarryR]

As per the slides davidp94 linked, BLAKE2s could be used instead of SHA256 to significantly reduce verification time, e.g. 10 rounds of 21518 constraints, versus 64 rounds of 25840 constraints. However Ethereum doesn't support BLAKE2s natively.

[barryWhiteHat]

I was thinking of going the jubjub route. Embed a twisted edwards curve in alt-bn-128253 and us that to do pedersen hashes, pedersen commitments. That would reduce the number of constraints drastically. But doing the pedersen in the EVM could be quite expensive gas wise. My intuition is we would have to wait for ewasm.

[HarryR]

Yup, even the response I had from one of the eth dev meetings was basically 'wait for ewasm'... Until then, I guess it's just about tooling, proof of concept, security, usability etc. and figuring out all those bits?

But I'm not sure I'd want to write code in Solidity when there's a C++ compiler that targets wasm...

Alternatively implement it all on EOS?

[barryWhiteHat]

Seems like it. But we can get pretty far with sha256 and zksnarks. Tho the biggest pain is the 7 min proving time. Tho i think we can get that down to 1 minute.

Oh do EOS have ec operations for alt-bn253? Or do they just use wasm?

[HarryR]

Getting the proving time down as much as possible is the HUUGE step towards general usability, maybe there some optimisations which can be made? Zcash's 40 second proving time is about as good as you're going to get at the moment.

EOS just use wasm, you'd have to link-in the library for alt-bn256.

[barryWhiteHat]

Yes. 40 seconds is a good target for now. But using Pedersen hashes and commitments we should be able to get this down a lot.