dalek-cryptography
Current capabilities of your r1cs
I have three questions, two general, one technical:
-
Are there any benchmarks for complex circuits in this library?
-
What needs to be done for the r1cs to become stable?
-
How would one perform a Pedersen Commitment in your circuit?
I like what Dalek has done and I am interested in benchmarking against other libraries.
Are there any benchmarks for complex circuits in this library?
The most complex is the N-shuffle and N-bit rangeproof. For 64-bit rangeproof (64 multipliers) we get ~1ms verification on a AVX2 backend with i7-7800X (https://doc.dalek.rs/bulletproofs/index.html). IFMA is 1.5x faster than that, but CPUs are not widely available yet with it.
Things like sha256 are most meaningfully compared with an optimized circuit. Naïve hand-built circuit w/o optimizations probably uses 4-5x more multiplication gates than what Bulletproofs paper uses (~100K vs ~25K), with hand-made optimized sub-gadgets, but still not algorithmically optimized I estimated about 31K multipliers. So it's still 20% off. And no one yet wrote an adaptor for the circuit format that is used by secp256k1 for benchmarks. So there is no benchmark for sha256 because writing adaptor is not fun, but manual implementation via the API is ~20% less optimal.
What needs to be done for the r1cs to become stable?
- Cf. issues list: https://github.com/dalek-cryptography/bulletproofs/issues
- Making sure the API is complete and sensible. E.g. should we have zero-cost iterator-style linear combinations, or current re-allocating Vec-based ones are fine? Or should we track assignments inside Variables, or let the upstream protocols do that if they need?
- Security proof for 2-phase challenge-based API.
How would one perform a Pedersen Commitment in your circuit?
It's not clear for which task you would need it. The Pedersen Commitments for variables are provided "for free": you don't need to construct them inside the circuit - just commit a variable with a given commitment and BP statements include them natively. However, if you need to do ECC inside a circuit, including Pedersen Commitments, then you first need to implement an embedded curve inside Ristretto group and implement its group operations. Then you can build commitments from there if you need to.
However, if you need to do ECC inside a circuit, including Pedersen Commitments, then you first need to implement an embedded curve inside Ristretto group and implement its group operations. Then you can build commitments from there if you need to.
Is there an ongoing effort to have these "basic" blocks like ECC (preferably Ristretto), hashes and perhaps block ciphers, or is this out of scope for you team?
but manual implementation via the API is ~20% less optimal
Is it available for testing? If we take into consideration that most developers may only want to use your api to build gadgets in a naïve manner at first, the manual implementation is also significant.
However, if you need to do ECC inside a circuit, including Pedersen Commitments, then you first need to implement an embedded curve inside Ristretto group and implement its group operations.
Is there an ongoing plan for this, or is it a feature that would be built by the open source community? I do not see an issue regarding this, so the latter was initially assumed.
For doing ECC inside of Ristretto, there is a nice way to build "Doppio" (Ristretto in Ristretto) that gives a prime-order group inside the circuit. Probably there will be an implementation in the next few months.
