Plonky2 GoldiBear implementation now it's generic on the field (the field must be two-adic and with at most 64 bits) enabling the support of both Goldilocks and BabyBear.
Plonky2 GoldiBear introduces the support for recursive proofs composition over both fields, using Poseidon over Goldilocks and Poseidon2 over BabyBear. The implementations of the fields and Poseidon2 are taken directly from the Plonky3 repo as dependencies.
This implementation solves also the Plonky2 issue 456 that was much more probable to happen using the BabyBear field (see commit).
For more details about the Plonky2 argument system, see this writeup.
Polymer Labs has written up a helpful tutorial here!
A good starting point for how to use Plonky2 for simple applications is the included examples:
factorial: Proving knowledge of 100!fibonacci: Proving knowledge of the hundredth Fibonacci numberrange_check: Proving that a field element is in a given rangesquare_root: Proving knowledge of the square root of a given field element
To run an example, use
cargo run --example <example_name>Plonky2 requires a recent nightly toolchain, although we plan to transition to stable in the future.
To use a nightly toolchain for Plonky2 by default, you can run
rustup override set nightly
in the Plonky2 directory.
To see recursion performance, one can run this bench recursion, which tests both fields:
RUSTFLAGS=-Ctarget-cpu=native cargo bench recursionTests can be simply run with:
cargo testUse --release for faster execution.
Given that the verification of proofs can be run also on different architectures (e.g. wasm32), there is a test that is meant to run on wasm32 (test_recursive_verifier_gl_regression).
To run such test, it's required to have nodejs installed (tested with versions v20.15.1 - v23.1.0) and wasm-pack (tested with version 0.13.0). The latter can be installed with:
cargo install wasm-packThen, the test can be run with:
cd plonky2 && wasm-pack test --nodePlonky2 prefers the Jemalloc memory allocator due to its superior performance. To use it, include jemallocator = "0.5.0" in your Cargo.toml and add the following lines
to your main.rs:
use jemallocator::Jemalloc;
#[global_allocator]
static GLOBAL: Jemalloc = Jemalloc;Jemalloc is known to cause crashes when a binary compiled for x86 is run on an Apple silicon-based Mac under Rosetta 2. If you are experiencing crashes on your Apple silicon Mac, run rustc --print target-libdir. The output should contain aarch64-apple-darwin. If the output contains x86_64-apple-darwin, then you are running the Rust toolchain for x86; we recommend switching to the native ARM version.
See CONTRIBUTING.md.
All crates of this monorepo are 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.
This code has not yet been audited, and should not be used in any production systems.
While Plonky2 is configurable, its defaults generally target 100 bits of security. The default FRI configuration targets 100 bits of conjectured security based on the conjecture in ethSTARK.
Plonky2's default hash function over Goldilocks is Poseidon, configured with 8 full rounds, 22 partial rounds, a width of 12 field elements (each ~64 bits), and an S-box of x^7.
Over BabyBear is Poseidon2, configured with 8 full rounds, 13 partial rounds, a width of 16 field elements (each ~31 bits), and an S-box of x^7. [BBLP22]
(https://tosc.iacr.org/index.php/ToSC/article/view/9850) suggests that these configurations may have around 95 bits of security, falling a bit short of our 100 bit target.