Hi, I have question about “zc-testnet-public-alpha-providing.key” file, downloaded during fetch-params.sh.
Could you, please, explain - why providing key is so big (~2GB)? what is purpose of that? what is the content of this file?
E.g. SSL certificate 4096 bit key is considered very secured.
Thanks!
Hi. This file is used to create zero-knowledge proofs, so it’s needed by any wallet that needs to send funds privately. (It’s not needed by nodes that don’t send private funds, such as verifier full nodes or miners.)
This version is not optimized, so we hope we can improve its size a lot.
though, why is key so big? it’s clear that it is used for zero knowledge proofs.
The size of the key depends on the size of the zkSNARK circuit. The circuit we are currently using --a small variation on the one in the Zerocash paper-- has over 4 million gates. (For reference, an implementation of SHA-256 requires about 27000 gates.) There is plenty of scope for optimising this; you can look at these tickets for details.
(Also, the current format of the file is somewhat space-inefficient.)
Pretty easy to add decompression to fetch-params.sh, so this might be an option going forward. On an i3 laptop, using parallel bz2, it took about 2 minutes to compress, and slightly less to decompress, with 60% saving.
lbzip2: compressing “regtest/zc-testnet-public-alpha-proving.key” to “regtest/zc-testnet-public-alpha-proving.key.bz2”
lbzip2: “regtest/zc-testnet-public-alpha-proving.key”: compression ratio is 1:2.563, space savings is 60.99%
1.9G zc-testnet-public-alpha-proving.key
747M zc-testnet-public-alpha-proving.key.bz2
The current files are compressible because they are using libsnark’s text-based serialization format. Switching to binary serialization (issues 799 and 416) will fix that. Then, the file will likely not be further compressible by much using general-purpose compression algorithms, although there will still be an improvement possible using elliptic curve point compression (issue 561).