Plonky2 & more

This repository was originally for Plonky2, a SNARK implementation based on techniques from PLONK and FRI. It has since expanded to include tools such as Starky, a highly performant STARK implementation.

Documentation

For more details about the Plonky2 argument system, see this writeup.

Polymer Labs has written up a helpful tutorial here!

Examples

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 number
range_check: Proving that a field element is in a given range
square_root: Proving knowledge of the square root of a given field element

To run an example, use

cargo run --example <example_name>

Building

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.

Running

To see recursion performance, one can run this bench, which generates a chain of three recursion proofs:

RUSTFLAGS=-Ctarget-cpu=native cargo run --release --example bench_recursion -- -vv

Jemalloc

Plonky2 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.

Guidance for external contributors

Do you feel keen and able to help with Plonky2? That's great! We encourage external contributions!

We want to make it easy for you to contribute, but at the same time we must manage the burden of reviewing external contributions. We are a small team, and the time we spend reviewing external contributions is time we are not developing ourselves.

We also want to help you to avoid inadvertently duplicating work that is already underway, or building something that we will not want to incorporate.

First and foremost, please keep in mind that this is a highly technical piece of software and contributing is only suitable for experienced mathematicians, cryptographers and software engineers.

The Polygon Zero Team reserves the right to accept or reject any external contribution for any reason, including a simple lack of time to maintain it (now or in the future); we may even decline to review something that is not considered a sufficiently high priority for us.

To avoid disappointment, please communicate your intention to contribute openly, while respecting the limited time and availability we have to review and provide guidance for external contributions. It is a good idea to drop a note in our public Discord #development channel of your intention to work on something, whether an issue, a new feature, or a performance improvement. This is probably all that's really required to avoid duplication of work with other contributors.

What follows are some more specific requests for how to write PRs in a way that will make them easy for us to review. Deviating from these guidelines may result in your PR being rejected, ignored or forgotten.

General guidance for your PR

Obviously PRs will not be considered unless they pass our Github CI. The Github CI is not executed for PRs from forks, but you can simulate the Github CI by running the commands in .github/workflows/ci.yml.

Under no circumstances should a single PR mix different purposes: Your PR is either a bug fix, a new feature, or a performance improvement, never a combination. Nor should you include, for example, two unrelated performance improvements in one PR. Please just submit separate PRs. The goal is to make reviewing your PR as simple as possible, and you should be thinking about how to compose the PR to minimise the burden on the reviewer.

Also note that any PR that depends on unstable features will be automatically rejected. The Polygon Zero Team may enable a small number of unstable features in the future for our exclusive use; nevertheless we aim to minimise the number of such features, and the number of uses of them, to the greatest extent possible.

Here are a few specific guidelines for the three main categories of PRs that we expect:

The PR fixes a bug

In the PR description, please clearly but briefly describe

the bug (could be a reference to a GH issue; if it is from a discussion (on Discord/email/etc. for example), please copy in the relevant parts of the discussion);
what turned out to the cause the bug; and
how the PR fixes the bug.

Wherever possible, PRs that fix bugs should include additional tests that (i) trigger the original bug and (ii) pass after applying the PR.

The PR implements a new feature

If you plan to contribute an implementation of a new feature, please double-check with the Polygon Zero team that it is a sufficient priority for us that it will be reviewed and integrated.

In the PR description, please clearly but briefly describe

what the feature does
the approach taken to implement it

All PRs for new features must include a suitable test suite.

The PR improves performance

Performance improvements are particularly welcome! Please note that it can be quite difficult to establish true improvements for the workloads we care about. To help filter out false positives, the PR description for a performance improvement must clearly identify

the target bottleneck (only one per PR to avoid confusing things!)
how performance is measured
characteristics of the machine used (CPU, OS, #threads if appropriate)
performance before and after the PR

Licenses

As this is a monorepo, see the individual crates within for license information.

Security

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 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. BBLP22 suggests that this configuration may have around 95 bits of security, falling a bit short of our 100 bit target.

unzvfu/plonky2-toposware