arkworks-rs/groth16

The arkworks ecosystem consist of Rust libraries for designing and working with zero knowledge succinct...

This library is released under the MIT License and the Apache v2 License (see License)

ark-groth16

The arkworks ecosystem consist of Rust libraries for designing and working with zero knowledge succinct non-interactive arguments (zkSNARKs). This repository contains an efficient implementation of the zkSNARK of [Groth16].

This library is released under the MIT License and the Apache v2 License (see License).

WARNING: This is an academic proof-of-concept prototype, and in particular has not received careful code review. This implementation is NOT ready for production use.

Build guide

The library compiles on the stable toolchain of the Rust compiler. To install the latest version of Rust, first install rustup by following the instructions here, or via your platform's package manager. Once rustup is installed, install the Rust toolchain by invoking:

After that, use cargo, the standard Rust build tool, to build the library:

This library comes with unit tests for each of the provided crates. Run the tests with:

License

This library is licensed under either of the following licenses, at your discretion.

  • Apache License Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
  • MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

Unless you explicitly state otherwise, any contribution submitted for inclusion in this library by you shall be dual licensed as above (as defined in the Apache v2 License), without any additional terms or conditions.

Acknowledgements

This work was supported by: a Google Faculty Award; the National Science Foundation; the UC Berkeley Center for Long-Term Cybersecurity; and donations from the Ethereum Foundation, the Interchain Foundation, and Qtum.

An earlier version of this library was developed as part of the paper "ZEXE: Enabling Decentralized Private Computation".

Issues

Collection of the latest Issues

burdges

burdges

Comment Icon0

Summary

We should support verifier SRS points for public inputs being independent of the circuit and other SRS elements, but maybe only optionally so. ZEXE-like schemes could then be build using MIPP proofs like SnarkPack, without wasting resources on slow recursion.

Proposal

At present, we discover verifier SRS points for public inputs only after performing a Groth16 trusted setup because Groth16 constructs verifier SRS points and prover SRS points for C similarly.

As an optional tweak, I'd propose that verifier SRS public input points should be at least partially constructed via hash-to-curve before running the SRS. We then add one additional prover SRS point for C for each public input point like this, which expresses the actual wiring and binds the hashed-to-curve public input points into the circuit.

We could then construct arbitrary circuits in the future which have (some of) the same public inputs as older circuits, which then simplifies using diverse Groth16 circuits within another proof system like SnarkPack.

We likely fix gamma=1 when doing this, but then each new circuit has its own fresh delta, making [delta]_2 possibly the unique place where SnarkPack proves correctness of the Groth16 circuits used. It's likely the groth16 crate only needs support for circuit Independence of public input SRS points though, and anything else can happen in other crates.

I'll likely convince someone in-house to work on this, but we'll want to upstream the changes, and this issue might spark useful conversation.


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
burdges

burdges

Comment Icon0

Summary

We should likely add batch verification like ZCash deployed eventually, and perhaps snarkpack.

Proposal

The ZCash issue https://github.com/zcash/librustzcash/issues/253#issuecomment-1026042373 has inbound links with further details.

In this vein, Arkworks might have or want other relevant abstractions, like MIPP, which maybe simplify SnarkPack, which requires more effort and perhaps another crate.


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
weikengchen

weikengchen

T-design
Comment Icon0

This issue describes the branch commit-carrying.

According to LegoSNARK, Groth16 is a commit-carrying SNARK with weak binding. With a small modification below, Groth16 can become a full-fledged commit-carrying SNARK. Note that Groth16 is commit-carrying, but not commit-and-prove because the commitment's parameters are relation-dependent.

The modification is as follows:

  • Augment the QAP so that the first n columns of the A matrices have a rank at least n, where n is the number of input elements. This step is done by simply adding n+1 constraints. A discussion is here: https://github.com/arkworks-rs/groth16/blob/commit-carrying/src/augmented_qap.rs#L1
  • Modify the data structures of proving keys and verifying keys accordingly.
  • Modify the proof generation and verification accordingly.

This issue is, very likely, not going to be merged into the master branch since its interface is drastically different.

weikengchen

weikengchen

D-medium
Comment Icon3

More updates will be added to this note.

I measured the cost for Groth16 to prove a constraint system with two million constraints, with a different number of cores, using cargo bench in this repo with appropriate command line parameters.

Below I focus on the main cost in my constraint system, which turns out to be in the witness map and computation of C.

Going from 1 core to 4 cores, the improvement is significant. But later when more cores are added, the time for the witness map seems to not change a lot.

Since the witness map involves a lot of FFT, it may suggest that the current implementation of FFT has a barrier toward many-many-core parallelism.

Such a barrier, maybe avoidable, maybe unavoidable. I will take a look at the detailed breakdown of the cost of the witness map.

nirvantyagi

nirvantyagi

T-bug
Comment Icon1

This issue was run into on the zexe library and has not been attempted to be reproduced on arkworks yet.

The constraints method verify for computing a BooleanVar representing whether a proof is valid or not produces unsatisfied constraints when a Default::default proof is passed as input. The correct behavior would be to simply return a BooleanVar with value false.

The method works as expected when passing in the correct proof (returns a true BooleanVar) or passing in a proof with values not initialized to Default, e.g. random group elements or canonical generator (returns a false BooleanVar). This indicates that there might be some odd behavior with how verify interacts with a proof that has 0 values (which I believe is what Default sets the group elements to).

https://github.com/arkworks-rs/groth16/blob/master/src/constraints.rs#L243

Versions

Find the latest versions by id

Information - Updated Aug 11, 2022

Stars: 82
Forks: 24
Issues: 6

Orion is a cryptography library written in pure Rust

It aims to provide easy and usable crypto while trying to minimize the use of unsafe code

Orion is a cryptography library written in pure Rust

Rustls is a modern TLS library written in Rust

ring for cryptography and rustls-pemfile crate

Rustls is a modern TLS library written in Rust

Mundane is a Rust cryptography library backed by BoringSSL that is difficult

to misuse, ergonomic, and performant (in that order)

Mundane is a Rust cryptography library backed by BoringSSL that is difficult

This repository holds a Rust port of Google's Tink cryptography library

This repository holds a Rust port of Google's RustCrypto crates – this repo focuses on making

This repository holds a Rust port of Google's Tink cryptography library

A cryptography library that is mainly implemented in Rust

I aim to implement bindings to other languages such as C/C++ and Python

A cryptography library that is mainly implemented in Rust

A collection of cryptography functions written in Rust

rustup -- curl --proto '=https' --tlsv1

A collection of cryptography functions written in Rust

The SIDH-RS library is an efficient supersingular isogeny-based cryptography library written in Rust language

The library includes the ephemeral Diffie-Hellman key exchange (SIDH) as described in [1,2]

The SIDH-RS library is an efficient supersingular isogeny-based cryptography library written in Rust language

Rust-based classical cryptography framework

Improve transposition nulls and allow cycling of nulls (i

Rust-based classical cryptography framework

A Rust implementation of the Cyclist mode of permutation-based cryptography

Includes Xoodyak and several Keccak-p based constructions (affectionately called Keccyak)

A Rust implementation of the Cyclist mode of permutation-based cryptography

Cryptography Utils for Rust

The driver is available on

Cryptography Utils for Rust

Lixur is being re-written in Rust

✅ Quantum Resistant Cryptography

Lixur is being re-written in Rust
Facebook Instagram Twitter GitHub Dribbble
Privacy