Weierstrass BN254 zero-knowledge trusted setup ceremony.

Go to file

Alex Vlasov 847b22826f add explicit non-infinity checks		2019-03-08 15:37:36 +01:00
src	add explicit non-infinity checks	2019-03-08 15:37:36 +01:00
.gitignore	prepare for testing for Ethereum related ceremony	2019-01-09 20:30:42 +02:00
Cargo.lock	update tools for more clear messages about hashes of files	2019-03-08 01:23:02 +01:00
Cargo.toml	use versioning for reproducible builds	2019-03-05 10:35:30 +01:00
COPYRIGHT	Initial commit	2017-10-29 18:58:34 -06:00
LICENSE-APACHE	Initial commit	2017-10-29 18:58:34 -06:00
LICENSE-MIT	Initial commit	2017-10-29 18:58:34 -06:00
README.md	prepare for testing for Ethereum related ceremony	2019-01-09 20:30:42 +02:00
test.sh	cleanup for freeze	2019-02-27 19:10:19 +03:00

README.md

Powers of Tau

Original story

This is a multi-party computation (MPC) ceremony which constructs partial zk-SNARK parameters for all circuits up to a depth of 2²¹. It works by taking a step that is performed by all zk-SNARK MPCs and performing it in just one single ceremony. This makes individual zk-SNARK MPCs much cheaper and allows them to scale to practically unbounded numbers of participants.

This protocol is described in a forthcoming paper. It produces parameters for an adaptation of Jens Groth's 2016 pairing-based proving system using the BLS12-381 elliptic curve construction. The security proof relies on a randomness beacon being applied at the end of the ceremony.

Contributions

Extended to support Ethereum's BN256 curve and made it easier to change size of the ceremony. In addition proof generation process can be done in memory constrained environments now. Benchmark is around 1.3 Gb of memory and 3 hours for a 2^26 power of tau on BN256 curve on my personal laptop

Instructions

Instructions for a planned ceremony will be posted when everything is tested and finalized.

Recommendations from original ceremony

Participants of the ceremony sample some randomness, perform a computation, and then destroy the randomness. Only one participant needs to do this successfully to ensure the final parameters are secure. In order to see that this randomness is truly destroyed, participants may take various kinds of precautions:

putting the machine in a Faraday cage
destroying the machine afterwards
running the software on secure hardware
not connecting the hardware to any networks
using multiple machines and randomly picking the result of one of them to use
using different code than what we have provided
using a secure operating system
using an operating system that nobody would expect you to use (Rust can compile to Mac OS X and Windows)
using an unusual Rust toolchain or alternate rust compiler
lots of other ideas we can't think of

It is totally up to the participants. In general, participants should beware of side-channel attacks and assume that remnants of the randomness will be in RAM after the computation has finished.

License

Licensed under either of

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)

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.