zkvm: encapsulate bulletproofs dependencies

[vickiniu]

Fixes #210 - uses capacity of 256 for bulletprooofs generator.

[oleganza]

We cannot hardcode this for two reasons:

1. Bigger txs will have larger circuits and more than 256 multipliers, failing the verification if 256 is hardcoded.
2. Computing generators is expensive. Validator would want to precompute them and use over its whole lifetime to validate arbitrary amount of transactions, so we need to pass it in.

Note: each rangeproof is 64 multipliers, each "lane" of Cloak is roughly 8+64=72 multipliers (8 for shuffles and mixes, 64 for output rangeproof). So the 10-input/output tx would use ≈720 multipliers. Plus custom contracts may allocate a few here and there.

[vickiniu]

Got it, so on the prover we'd want to calculate the capacity that we need?

If the verifier might want to precompute generators, would we need to keep bp_gens as a parameter on verify_tx?

[oleganza]

Yeah, that's why this discussion was prompted: https://dalek-cryptography.slack.com/archives/CBKMRC8DN/p1552425846018800

[oleganza]

As of exposing BP API, we could re-export only BulletproofGens in the lib.rs to allow user precompute them and pass into verifier. This way if they don't care about other parts of R1CS, they can avoid explicitly linking with bulletproofs crate.

[vickiniu]

got it, that makes sense! reading slack thread now :)

[oleganza]

We should probably simply do pub use bulletproofs; in the lib.rs to allow users pick various bulletproofs types (such as generators) directly via zkvm::bulletproofs::... to avoid adding BP as a dependency.